Re: [RFE] Please add a standard ref object to releases
- Date: Thu, 01 Nov 2018 14:09:13 +0100
- From: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
- Subject: Re: [RFE] Please add a standard ref object to releases
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
>> 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://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
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"
>> 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