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
