Web lists-archives.com

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.


Nicolas Mailhot