On Thu, Nov 01 2018, Nicolas Mailhot wrote: > 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. Yeah I think it says a lot about how vague your proposal is. You're the one trying to ostensibly file some sort of bug report or feature request, it's up to you to explain the problem in detail. > 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 And would these also be annotated tags, or are you proposing that we add a new "release" object type in addition to blob/tree/commit/tag? If so what would that look like? > 2. there was a git syntax to say "the release “x.y.z”" ref in all git > commands that manipulate refs What do you mean "git syntaX"? The rev-parse syntax (see 'git help rev-parse`) or something else? > 3. that this "release “x.y.z”" ref could be used in all the "download > release “x.y.z”" on GitLab/GitHub, etc So instead of offering a download of annotated tags as they do now, see https://github.com/git/git/releases and https://gitlab.com/git-vcs/git/tags they'd offer a download of whatevr this new thing is? > 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 So since we'd store this in refs/* somewhere since it's (presumably) named named ref of some sort, you're suggesting that this thing be exempt from the DWYM name resolution of refs, e.g. us resolving "master" to "refs/heads/master" or v1.0 to "refs/tags/v1.0" (but as you note that's ambiguous). So you'd always need to do e.g. "git show refs/releases/v1.0"? > 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 I don't know what you mean by "syntax" and "selection" in this context. > 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. I'm still entirely unclear about "does not work" here. > 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. This seems like another complaint about the ref ambiguities. That's fair enough, but how is that per-se related to this proposal? We also have ambiguity now between "master" tags and branches. >> 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. It's not over-engineering. Right now we have a hierarchical namespace for tags and branches, so if you want N levels deep or whatever you do that with prefixes or subdirectories, and there's plenty of examples of that in the wild. E.g. tags created for hacking, QA, pre-release, release, LTS etc. Whereas if you're proposing some mechanism that we draw a line somewhere in that flow and say "now tag/mark/release stuff as different sorts of objects" it's up to you to convince us why that's a realistic view of the world.
