rks.
So, unless someone wants to revisit git commit, we’re left with
imperfect solutions, and git credentials is no worse than another. It
certainly fixes my use case fine. You did good work in git credentials.
Regards,
--
Nicolas Mailhot
Le vendredi 02 novembre 2018 à 09:27 +0100, Christian Couder a écrit :
> On Thu, Nov 1, 2018 at 3:42 PM Nicolas Mailhot
> wrote:
> > Le jeudi 01 novembre 2018 à 15:13 +0100, Christian Couder a écrit :
> > > How can Git know when you commit where you will want to push the
&g
> need different credentials?
Then you do not use git credentials and have to configure all by hand.
Which will usually be a major error-prone PITA, so you’ll end up pushing
to the system that matches the ID you want to se in git logs, and then
push from this system to others.
--
Nicolas Mailhot
e had to
define separate sections for releases and tags in its UI.
If tags and release were the same thing one could take random git
projects on github or gitlab and apply release rules like semver to
their tags. Even projects that use semver do not have semver-only tags,
and even their semver tags cant'd be semvered as-is because of random
injections of prefixes like v or version.
Regards,
--
Nicolas Mailhot
56874
name = John Doe, Snr Engineer
email = john@corp.com
Instead of just
[user]
name = John Doe
email = john@corp.com
[credential "https://pkgs.fedoraproject.org/";]
username = doe4ever
[credential "https://gitlab.corp.com/";]
username = jdoe56874
and drat, I've commited to XXX with the wrong name/email again
--
Nicolas Mailhot
o separate them from normal tags in its UI. I'm not aware of the same
thing for LTS or whatever.
Of course implementing generic namespacing, would be a way to get a
separate release namespace. As long as this release namespace is
unambiguously defined at the git level without replaying the 'just
invent your own tag recipe' mess at another level.
Regards,
--
Nicolas Mailhot
Le jeudi 01 novembre 2018 à 10:59 +0100, Nicolas Mailhot a écrit :
> Hi,
>
> A dev persona is not just a username, please add email (and probably
> also name) support to git credentials so the correct set for a repo
> url
> is automatically picked up by git
So, just in cas
k.
Please add a specific release reference to git, so software projects
that do versioned releases can use this ref object directly, without
needing to invent custom version rewriting rules to shove them in tags
while marking they are not just tags but release references.
Regards,
--
Nicolas Mailhot
Hi,
A dev persona is not just a username, please add email (and probably
also name) support to git credentials so the correct set for a repo url
is automatically picked up by git
Regards,
--
Nicolas Mailhot
scheme for decades with little
changes. The remaining differences are slowly being eroded by the wish to
automate everything.
Regards,
--
Nicolas Mailhot
They would make releasing more predictable and reliable
>> for people deploying the code, and easier
>> to consume by higher-level cross-project management tools. That would
>> transform the deployment stage of software
>> just like Git already transformed early code writing and autotest stages.
> Possibly, but primarily for source releases.
Sure, you need to start somewhere, and git's job is managing sources, so source
releases are part of its theoritical scope.
Best regards,
--
Nicolas Mailhot
ng they have the same environment and
>> > needs).
>>
>> If you take the time to look at it it is not specific, it is generic.
>>
>I would say that you might haven't looked broadly enough.
> 1) If it's generic, why isn't there any "generic" release management
> tool?
Why didn't git exist from day one? Is git not generic?
> 2) if it's possible to create a "generic" release management tool and
> it just doesn't exist yet, why not try to create instead of trying to
> integrate release management into Git ?
Because the whole point of Git is to track project states and a release is just
a particular state (that happens to be useful for users of a project, not its
own devs, which is why it was not included in git from day one. That didn't
stop Linus from doing releases manually).
>> You need to identify software during
>> its whole lifecycle, and the id needs to start in the scm, because
>> that's where the lifecycle starts.
> It might not for everyone!
Please present actual facts, that can be discussed.
Regards,
--
Nicolas Mailhot
; stabilizing state and cutting a release.
> This is all process specific to your environment. Consider e.g. the
> C++ standard committee tracking the C++ Standard in Git .
> https://isocpp.org/std/the-committee
> They make a release every 10 years or such, so 3 month is off!
Actually you'll find out that they do intermediary pre-standard releases way
more often. 3 months is the average that works for most projects. I don't
propose to set it in stone, just as a sane default.
> Integrating with CI and release is definitely important, but Git
> itself has no idea about the requirements and environments of the
> project specifics,
The proposal is not just about CI. The software life does not end when a dev
pushes code to CI. You need to identify software during its whole lifecycle,
and the id needs to start in the scm, because that's where the lifecycle starts.
Right now the only shared id that does not depend on project environment that
git proposes is commit hashes, and it is terrible in post-dev stages of the
lifecycle.
Regards,
--
Nicolas Mailhot
leasing
easier, less tedious, and cheaper for developers, that formalize, automate, and
make easier existing practices of mature software projects, making them
accessible to smaller projects. They would make releasing more predictable and
reliable for people deploying the code, and easier to cons
14 matches
Mail list logo
