Re: [RFE] Please add name and email to git credentials
Le vendredi 02 novembre 2018 à 12:51 -0400, Jeff King a écrit : Hi, Thank you for reading the RFE. > I did create the way git credential matches repo urls. And I do not > think your proposal is a good idea. The credential system is about > interacting with a remote URL, and creating a commit object is a local > operation. That mismatch leaks through when you work with multiple > remotes, since it is not clear which URL we would match against when > the operation does not involve a remote at all. I don't think it's quite that simple. The id part of creating a commit object is not a local operation at all. You choose the id written in a commit for a specific remote target, it has no use locally, most of us do not need it to reach themselves. So yes there is a leak but it’s built in the git commit logic itself. Ideally, git would defer resolving in commits to when I push to a remote target. I'm sure you’re aware of all the workarounds git users do at push time, when they realize the commit is not the good one. And since the leak is built in the commit logic itself, there are no perfect solutions that do not involve revisiting how commit works. 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
Re: [RFE] Please add name and email to git credentials
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 > > > commit afterwards? > > > > You have an url in the repo config. of course you can change it > > between > > the commit and the push, but that's not the general case. > > If I did a `git init`, then I have no url in the repo config. Also if > I cloned from a repo that has a different URL than the sites I have > credentials for, then how should git use the URL in the repo config? Then you have no need or use for git credentials. Where’s the problem? Will the fact that git credential users, that already have per-repo-url settings in their .gitconfig, will also be able to use this existing per-url section to control the mail and name associated with their repos, wake you at night, or something? > You could have no user.name and user.email configured in your global > config, and a script that configures those in the local config > depending on remote.origin.url. One could use the same arguments to say git credentials is not necessary, it's a maintenance burden, everyone should just script their auth needs manually, etc. Are you arguing for git credentails removal here? Or are you arguing that having two separate mecanisms in git, to match config directives to repo urls, is some kind of improvement? I didn't create or write or specify the way git credential matches repo urls. It already exists within git. If you have a problem with the matching logic git credential uses, why are you arguing with me instead of taking it up with the maintainers of this logic? Regards, -- Nicolas Mailhot
Re: [RFE] Please add name and email to git credentials
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 > commit afterwards? You have an url in the repo config. of course you can change it between the commit and the push, but that's not the general case. Nowadays, most git projects have a preferred git hosting, and your name/email with the project match the credentials you use to push (otherwise things like gitlab/github issues trackers would not work at all). > What if you want to push the same commit to 2 different places that > 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
Re: [RFE] Please add a standard ref object to releases
the world github wouln’t have 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
Re: [RFE] Please add name and email to git credentials
Le jeudi 01 novembre 2018 à 12:22 +0100, Ævar Arnfjörð Bjarmason a écrit : > > Where would we get an E-Mail to lookup to pass to the helper? Are you > just asking that the helper git the result of $(git config user.name > && > git config user.email)? If so why can't it just look this up itself? So, just in case it was not clear enough, allow things in .gitconfig like [credential "https://pkgs.fedoraproject.org/;] username = doe4ever name = John Doe email = doe4e...@fedoraproject.org [credential "https://gitlab.corp.com/;] username = jdoe56874 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
Re: [RFE] Please add a standard ref object to releases
Le jeudi 01 novembre 2018 à 12:15 +0100, Ævar Arnfjörð Bjarmason a écrit : > > For both this and your other report, it would be helpful if you > describe > in concrete terms (with examples of git commands, or UI etc.) what git > commands do now, what's wrong with it, and some sketch of what you > expect an alternate interface to look like. > > As for this report: I know this area of git quite well, but I still > have no idea quite what you're asking for. It says a lot that you claim to know this area of git quite well, but have no understanding how it is (mis)used on github/gitlab/bitbucket/etc by people who actually try to use git. I’m just asking that when a project releases “x.y.z” 1. there was a standard git command available to it to create "the release “x.y.z”" ref 2. there was a git syntax to say "the release “x.y.z”" ref in all git commands that manipulate refs 3. that this "release “x.y.z”" ref could be used in all the "download release “x.y.z”" on GitLab/GitHub, etc 4. that there was no fuziness or human interpretation involved into converting "x.y.z" into the syntax used to select "release “x.y.z”" in git commands 5. there was no ambiguïty in this syntax that led to the selection of things that are not "release" refs and just look like them And **not** the current situation where there are no official "release ref" objects and "just map release names to tags, mapping recipe is left to the reader". Because everyone invents its own recipe and the result does not work. And no, vfoo is not a form of release ref, because v1 can be a branch, not a tag, version3 tag is not the release ersion3, etc (real-world examples I can provide links if you don't believe me). You can’t let things undefined as they are now because git users as a whole are making a mess of things without tooling help. > If we assume this is a good idea, how do you imagine this would work > once you don't just have two levels (random labels v.s. "real" > releases) > but three or more (random labels v.s. "real" releases v.s. "LTS" > releases, )? IMHO you’re over-engineering things there. There is a need for separate release refs, as evidenced by the fact every major git web frontend had to 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
Re: [RFE] Please add name and email to git credentials
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 case it was not clear enough, allow things in .gitconfig like [credential "https://pkgs.fedoraproject.org/;] username = doe4ever name = John Doe email = foo4e...@fedoraproject.org [credential "https://gitlab.corp.com/;] username = jdoe56874 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 email = f...@fedoraproject.org [credential "https://gitlab.corp.com/;] username = jdoe56874 and drat, I've commited to XXX with the wrong name/email again -- Nicolas Mailhot
[RFE] Please add a standard ref object to releases
Hi, git makes no provision for versioned release references. However, software projects need versioned releases. Software project integrators need versionned releases. Security auditors need versioned release. Software project users need versioned releases. Versioned releases are not the same thing as free-form tags. They have semantics to allow deducing upgrade paths (usually, a form of semver). They imply some form of API stability promise. They imply release documentation completion. They're not just a random point in the project history like tags are. This is why most git hosting sites provide a way to select versioned releases, even if it's not a native git concept. And this way is clearly separate and distinct from git tag selection. Unfortunately, since git makes no provision for versioned release references, git hosting sites have to shove release refs into tag refs. And it's a huge mess. Some put release ids in tags as-is, others add a v prefix, others a version_ prefix, it's all hoster-specific, it's all inconsistent. It ends up being inconsistent within projects, as they migrate from a hoster to another, are mirrored from one hoster to another. It depends on the habits of the person cutting a release, and the release manager of a project can change over time. It ends up being inconsistent in release archives, as the version munging can percolate in the archive name and structure, or not, for mysterious heuristic reasons that change over time. As a result, when assembling a project that uses other git repositories, you spend more time checking repository by repository and version by version how the version ref was mangled in a tag ref for this specific (repo,version,date) tuple, than doing actual software dev and QA work. 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
[RFE] Please add name and email to git credentials
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
Re: [RFE] Add minimal universal release management capabilities to GIT
- Mail original - De: "Jacob Keller" Hi Jacob, > I think that this could easily be built by a separate script which provides > git release command line and uses tags under the hood in a > well formed way. True, the difficulty is not technical, the whole scheme is basic and KISS. > I wouldn't say that the method outlined here works for all projects but I do > agree it's fairly common and could work for many projects I would be very surprised if there was a strong technical reason that stopped any project from adopting this scheme. Like I already wrote, Linux packaging tools work by converting public release naming to this scheme (with some additional twists, mostly there to help conversion of terminally broken, tooling-hostile and usually legacy projects, not worth the pain to import in new tooling). > I think most large projects already use annotated tags and tho they have > their own format it works pretty well. Raw tags are useless as release ids for tooling so everyone is forced to invent something else as soon as the project complexity passes a threshold (that's the point were there is no choice but to redefine tags, not the point were it starts being useful). I've already detailed why their laxity makes them useless. > Showing a tool that could help projects create more standardized release tags > would be helpful. > > I think such a tool could already be built, scripted to create annotated tags > with a well formed name. I don't think you necessarily > need to have this in core git, tho I do see that your main goal is to > piggyback on git itselfs popularity I see little hope for such a tool. Reimplementation is too trivial and convention drift only starts to be acutely painful past a certain size. At that size you're almost certain to have already started using a custom implementation, with refactoring costs impeding switching to a generic tool. Basically, it can only be done with a good probability of success by piggybacking on something that already federates a large number of Git users: – Git itself, which is the correct most productive and least painful place for everyone involved – one of the big Git-based forges, ie GitHub or GitLab. I'd expect it would be very tempting for one of those to make something that would effectively be a better Git than upstream Git, the usual embrace and extend effect. – development language ecosystems (Python, Ruby, Go, etc). There are already many premises of such work since build automation needs ids that can be processed by tools. The problem with letting forges or language ecosystems sort it is that you'll end up with functionally equivalent implementations, but divergent implementation details that end up wasting everyone's time. Like, decimal separator differences, deb vs rpm, car driving side, we humans managed to create the same clusterfuck time and time again. And much swearing every time you have a project that requires bridging those divergences. It would be worth it if the divergence and competition helped new ground-breaking schemes to emerge but really, look at it, it's not rocket science. Everyone has been using about this scheme for decades with little changes. The remaining differences are slowly being eroded by the wish to automate everything. Regards, -- Nicolas Mailhot
Re: [RFE] Add minimal universal release management capabilities to GIT
- Mail original - De: "Randall S. Becker" >> Git is a wonderful tool, which has transformed how software is created, and >> made code sharing and reuse, a lot easier (both >> between human and software tools). >> Please please please add release handling and versioning capabilities to Git >> itself. Without it some enthusiastic >> Git adopters are on a fast trajectory to unmanageable hash soup states, even >> if they are not realising it yet, because >> the deleterious side effects of giving up on releases only get clear with >> time. >> Here is what such capabilities could look like (people on this list can >> probably invent something better, I don't care as >>clong as something exists). > Nicolas makes some interesting points, and I do suggest looking at the > original post, but there are more factors to consider > when dealing with > production-grade releases in regulatory environments. And my sincere > apologies for what, even in my eyes > looks like a bit of a soap-box rant. No slight intended, Nicolas. Hi Randall. I plead guilty for the rant part, I've spent way too many nightly hours recently untangling Git projects that couldn't be bothered with stating requirements any other way than with a list of commit hashes, when they bothered (in one case a dev didn't even realise had broken some of his other projects when changing code, that's how bad the "a commit hash is a sufficient coordination point" situation is now getting). > Possibly most importantly, there are serious distinctions between what is > built via CI, what is released, and what is > installed. Perhaps I should clarify, my post was about "source" release id since git is a "source" code manager. You do need a different id to identify release builds (packaged or not). However, any sane system will derive the build id from the source id, since most software properties (options, functionnalities, security problems) are directly caused by what's in the source itself, and changing them requires going back to the source. > In a specific way, source and release commits are required to be time > reversible in production, whereby if an installation > fails, there exist in many environments requirements to be able to fully undo > the install action. This is often different > from the environment artifacts which can be time-forward constrained and > reversible only in extreme situations. Yes the reversibility is often very theorical, basically requiring losing any change and reverting to a pre-change data dump. Automation is getting to the point where it' simpler to push a new fixed build than reverting to previous state. But that requires solid handover between source-oriented (git), build-oriented, deployment-oriented and audit-oriented tools. >> So nothing terribly complex, just a lot a small helpers to make releasing >> 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 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
Re: [RFE] Add minimal universal release management capabilities to GIT
scm before most projects settled on git. All commonalities >> need to migrate in the common git layer to simplify management and >> release id is the first of those. > It's better to have a "good" (generic) release management tool that > does what you ask (probably with some help from git) than try to turn > Git into one (which is not possible without making Git opinionated, > more on that later). Be my guest, try to define the "some help from git", you'll end up with very similar requirements to mine. For most because you can't do less to be useful, for others because they are trivial to add once the rest is done and it would be woefully inefficient not to do them at the same time. > I guess there should already be one that meets > your expectation and you probably just have to discover it. Funny, it seems the scores of Git projects I have used those past months are in the same situation. Maybe that's because there's no sense in building a standalone tool? Tracking project states is the whole point of Git, you can overlay other tracking systems over the SCM, the end result is inconvenient in the absence of SCM cooperation. That's why so many people are starting to use git commit hashes in places they've never been designed for and are not adapted too. They are fed up with translating between the scm and the overlays. > Further, if there's no "generic" release management tool in existence, > I suspect that because there's no such thing a "generic release > management strategy" There may be no such thing as a generic release management strategy. There are such things as generic release management steps, which is the only part I propose to automate. Linux package management relies on those commonalities, and they have decades of successful deployment of all kinds of projects by very different authors with very different opinions that sort of prove those commonalities exist. > and it always depends on context (or) create one > on your own in the spirit of letting "git" handle just "version > control" and letting your "genereic" tool handle your concerns. Who > knows, if you have developed a good enough "generic" tool it might be > used widely for "release management" just as a lot of projects starting > using Git for "version control". (I still suspect that there should be > one that already exists) Again the problem is not the technical bits, they are rather trivial, the problem is scm integration which can't be solved outside git itself. >> > git tags ? >> >> Too loosely defined to be relied on by project-agnostic tools. That's >> what most tools won't ever try to use those. Anything you will define >> around tags as they stand is unlikely to work on the project of >> someone else > They are loosely defined because you can't define them "tightly" and if > you try to it would make Git opinionated !? That makes them useless for tooling. Any automation will require removing ambiguities humans relish. Keep tags for humans, add release ids for tools. Making Git unambiguous is not the same thing as giving Git opinions (except when the opinion is "don't use release ids cools can't process"). >> > > 5. a command, such as "git release", allow a human with control of the >> > > repo to set an explicit release version to a commit. >> > >> > This sounds fairly specific to an environment that you are in, maybe >> > write git-release for your environment and then open source it. The >> > world will love it (assuming 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
Re: [RFE] Add minimal universal release management capabilities to GIT
vention the release state of a repo is initialised at >> 0.0, for its first commit (tools can rely on at >> least one release >> existing in a repo). > An initial repo doesn't have tags, which comes close to 0. And it's not defined anywere so some will insist history starts at 1 or at -52 BC or whatever. Explicit convention enforced by tooling that others tools can rely on trumps implicit convention that can be argued to death all the time. >> 5. a command, such as "git release", allow a human with control of the repo >> to set an explicit release version to a commit. > This sounds fairly specific to an environment that you are in, maybe > write git-release for your environment and then open source it. The > world will love it (assuming they have the same environment and > needs). If you take the time to look at it it is not specific, it is generic. But, anyway yet another project bubble presents no value. The value of conventions is that they are shared, not that they are better than the neighbour's. I'll applaud anything done at git level because all the other tools and humans rely on this level. I'm sick of looking at conversion heuristics between higher-level tools, because they can't rely on scm-level conventions. >> 9. a command, such as "git release cut", > git -archive comes to mind, doing a subset here. It is not complex to do. The value is not on its complexity, the value is in setting conventions others can rely on. >> 11. when no releasing has been done in a repo for some time (I'd suggest 3 >> months to balance freshness with churn, it can >> be user-overidable in repo >> config), git reminds its human masters at the next commit events they should >> think about >> 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
[RFE] Add minimal universal release management capabilities to GIT
(a project may wish to promote a minor release to major one after it passes QA, versionning history should not be lost). 4. absent human intervention the release state of a repo is initialised at 0.0, for its first commit (tools can rely on at least one release existing in a repo). 5. a command, such as "git release", allow a human with control of the repo to set an explicit release version to a commit. Git enforces ordering (refuses versions lower than the latest repo version in git history). The most minor number of the explicit release is necessarily zero. 6. a command, such as "git release" without argument, allows a human to request setting of a minor patchlevel release version for the current commit. The computed version is: "last release version in git history except most minor number" + "." + "number of commits in history since this version" (patchlevel versioning is predictable and decentralized, credits to Willy Tarreau for the idea) 7. a command, such as "git release bump", allows a human to request setting of a new non-patchlevel release version. The computed version is "last release version in git history except most minor number, incrementing the remaining most minor number" + "." + "0" 8. a command, such as "git release promote", allows a human to request setting a new more major release version. The computed version is "last release version in git history except most minor number, incrementing the next-to-remaining-most-minor-and-non-zero number, and resetting the remaining-most-minor-and-non-zero number to zero" + "." + "0" 9. a command, such as "git release cut", creates a release archive, named reponame-releaseversion.tar.xz, with a reponame-releaseversion root directory, a reponame-releaseversion/VERSION file containing releaseversion (so automation like makefiles can synchronize itself with the release version state), removing git metadata (.git tree) from the result. If the current commit has several release objects attached the highest one in ordering is chosen. If the current commit is lacking a release object a new minor patchlevel release version is autogenerated. Archive compression format can be overridden in repo config. 10. a command, such as "git release translate", outputs the commit hash associated to the version given in argument if it exists, the version associated to the commit hash given in argument if it exists, the version associated to the current commit without argument. If it is translating commit hashes with no version it outputs the various versions that could be computed for this hash by git release, git release bump, git release promote. This is necessary to bridge developer-oriented tools, that will continue to talk in commit hashes, and release/distribution/security-audit oriented tools, that want to manipulate release versions 11. when no releasing has been done in a repo for some time (I'd suggest 3 months to balance freshness with churn, it can be user-overidable in repo config), git reminds its human masters at the next commit events they should think about stabilizing state and cutting a release. So nothing terribly complex, just a lot a small helpers to make releasing 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 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. Best regards, -- Nicolas Mailhot
