{"thread":{"id":"49730","subject":"[RFE] Please add a standard ref object to releases","startedAt":"2018-11-01T10:29:25Z","lastAt":"2018-11-01T14:32:18Z","messageCount":5,"participants":["Nicolas Mailhot","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"362159","messageId":"b639c19a881476be2d4dbdd731cd305384b287a9.camel@laposte.net","threadId":"49730","inReplyTo":null,"subject":"[RFE] Please add a standard ref object to releases","fromName":"Nicolas Mailhot","fromEmail":"nicolas.mailhot@laposte.net","sentAt":"2018-11-01T10:29:20Z","receivedAt":"2018-11-01T10:29:25Z","isPatch":false,"sender":{"key":"nicolas.mailhot@laposte.net","avatar":null},"body":"Hi,\n\ngit makes no provision for versioned release references.\n\nHowever, software projects need versioned releases. Software project\nintegrators need versionned releases. Security auditors need versioned\nrelease. Software project users need versioned releases.\n\nVersioned releases are not the same thing as free-form tags. They have\nsemantics to allow deducing upgrade paths (usually, a form of semver).\nThey imply some form of API stability promise. They imply release\ndocumentation completion. They're not just a random point in the project\nhistory like tags are.\n\nThis is why most git hosting sites provide a way to select versioned\nreleases, even if it's not a native git concept. And this way is clearly\nseparate and distinct from git tag selection.\n\nUnfortunately, since git makes no provision for versioned release\nreferences, git hosting sites have to shove release refs into tag refs.\nAnd it's a huge mess.\n\nSome put release ids in tags as-is, others add a v prefix, others a\nversion_ prefix, it's all hoster-specific, it's all inconsistent. It\nends up being inconsistent within projects, as they migrate from a\nhoster to another, are mirrored from one hoster to another. It depends\non the habits of the person cutting a release, and the release manager\nof a project can change over time. It ends up being inconsistent in\nrelease archives, as the version munging can percolate in the archive\nname and structure, or not, for mysterious heuristic reasons that change\nover time.\n\nAs a result, when assembling a project that uses other git repositories,\nyou spend more time checking repository by repository and version by\nversion how the version ref was mangled in a tag ref for this specific\n(repo,version,date) tuple, than doing actual software dev and QA work.\n\nPlease add a specific release reference to git, so software projects\nthat do versioned releases can use this ref object directly, without\nneeding to invent custom version rewriting rules to shove them in tags\nwhile marking they are not just tags but release references.\n\nRegards,\n\n\n-- \nNicolas Mailhot\n\n"},{"id":"362161","messageId":"871s85kq16.fsf@evledraar.gmail.com","threadId":"49730","inReplyTo":"b639c19a881476be2d4dbdd731cd305384b287a9.camel@laposte.net","subject":"Re: [RFE] Please add a standard ref object to releases","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-11-01T11:15:01Z","receivedAt":"2018-11-01T11:15:07Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Nov 01 2018, Nicolas Mailhot wrote:\n\n> git makes no provision for versioned release references.\n>\n> However, software projects need versioned releases. Software project\n> integrators need versionned releases. Security auditors need versioned\n> release. Software project users need versioned releases.\n>\n> Versioned releases are not the same thing as free-form tags. They have\n> semantics to allow deducing upgrade paths (usually, a form of semver).\n> They imply some form of API stability promise. They imply release\n> documentation completion. They're not just a random point in the project\n> history like tags are.\n>\n> This is why most git hosting sites provide a way to select versioned\n> releases, even if it's not a native git concept. And this way is clearly\n> separate and distinct from git tag selection.\n>\n> Unfortunately, since git makes no provision for versioned release\n> references, git hosting sites have to shove release refs into tag refs.\n> And it's a huge mess.\n>\n> Some put release ids in tags as-is, others add a v prefix, others a\n> version_ prefix, it's all hoster-specific, it's all inconsistent. It\n> ends up being inconsistent within projects, as they migrate from a\n> hoster to another, are mirrored from one hoster to another. It depends\n> on the habits of the person cutting a release, and the release manager\n> of a project can change over time. It ends up being inconsistent in\n> release archives, as the version munging can percolate in the archive\n> name and structure, or not, for mysterious heuristic reasons that change\n> over time.\n>\n> As a result, when assembling a project that uses other git repositories,\n> you spend more time checking repository by repository and version by\n> version how the version ref was mangled in a tag ref for this specific\n> (repo,version,date) tuple, than doing actual software dev and QA work.\n>\n> Please add a specific release reference to git, so software projects\n> that do versioned releases can use this ref object directly, without\n> needing to invent custom version rewriting rules to shove them in tags\n> while marking they are not just tags but release references.\n\nFor both this and your other report, it would be helpful if you describe\nin concrete terms (with examples of git commands, or UI etc.) what git\ncommands do now, what's wrong with it, and some sketch of what you\nexpect an alternate interface to look like.\n\nAs for this report: I know this area of git quite well, but I still have\nno idea quite what you're asking for.\n\nDo you just mean that we should have some other second-level namespace\nfor tags, i.e. in addition to refs/tags/* we'd have\nrefs/this-time-I-really-meant-it-tags/*., and e.g. linux.git and git.git\nv* tags would go into that, and have some \"git tag --i-really-mean-it\"\ninterface?\n\nIf we assume this is a good idea, how do you imagine this would work\nonce you don't just have two levels (random labels v.s. \"real\" releases)\nbut three or more (random labels v.s. \"real\" releases v.s. \"LTS\"\nreleases, ....)?\n"},{"id":"362169","messageId":"c414f7ae84c763cacd55d14ba68fbf2572b65132.camel@laposte.net","threadId":"49730","inReplyTo":"871s85kq16.fsf@evledraar.gmail.com","subject":"Re: [RFE] Please add a standard ref object to releases","fromName":"Nicolas Mailhot","fromEmail":"nicolas.mailhot@laposte.net","sentAt":"2018-11-01T12:26:28Z","receivedAt":"2018-11-01T12:26:34Z","isPatch":false,"sender":{"key":"nicolas.mailhot@laposte.net","avatar":null},"body":"Le jeudi 01 novembre 2018 à 12:15 +0100, Ævar Arnfjörð Bjarmason a\nécrit :\n> \n> For both this and your other report, it would be helpful if you\n> describe\n> in concrete terms (with examples of git commands, or UI etc.) what git\n> commands do now, what's wrong with it, and some sketch of what you\n> expect an alternate interface to look like.\n> \n> As for this report: I know this area of git quite well, but I still\n> have no idea quite what you're asking for.\n\nIt says a lot that you claim to know this area of git quite well, but\nhave no understanding how it is (mis)used on github/gitlab/bitbucket/etc\nby people who actually try to use git.\n\nI’m just asking that when a project releases “x.y.z”\n\n1. there was a standard git command available to it to create \"the\nrelease “x.y.z”\" ref\n\n2. there was a git syntax to say \"the release “x.y.z”\" ref in all git\ncommands that manipulate refs\n\n3. that this \"release “x.y.z”\" ref could be used in all the \"download\nrelease “x.y.z”\" on GitLab/GitHub, etc\n\n4. that there was no fuziness or human interpretation involved into\nconverting \"x.y.z\" into the syntax used to select \"release “x.y.z”\" in\ngit commands\n\n5. there was no ambiguïty in this syntax that led to the selection of\nthings that are not \"release\" refs and just look like them\n\nAnd **not** the current situation where there are no official \"release\nref\" objects and \"just map release names to tags, mapping recipe is left\nto the reader\". Because everyone invents its own recipe and the result\ndoes not work.\n\nAnd no, vfoo is not a form of release ref, because v1 can be a branch,\nnot a tag, version3 tag is not the release ersion3, etc (real-world\nexamples I can provide links if you don't believe me). You can’t let\nthings undefined as they are now because git users as a whole are making\na mess of things without tooling help.\n\n> If we assume this is a good idea, how do you imagine this would work\n> once you don't just have two levels (random labels v.s. \"real\"\n> releases)\n> but three or more (random labels v.s. \"real\" releases v.s. \"LTS\"\n> releases, ....)?\n\nIMHO you’re over-engineering things there. There is a need for separate\nrelease refs, as evidenced by the fact every major git web frontend had\nto separate them from normal tags in its UI. I'm not aware of the same\nthing for LTS or whatever.\n\nOf course implementing generic namespacing, would be a way to get a\nseparate release namespace. As long as this release namespace is\nunambiguously defined at the git level without replaying the 'just\ninvent your own tag recipe' mess at another level.\n\nRegards,\n\n-- \nNicolas Mailhot\n\n"},{"id":"362173","messageId":"87y3adj66e.fsf@evledraar.gmail.com","threadId":"49730","inReplyTo":"c414f7ae84c763cacd55d14ba68fbf2572b65132.camel@laposte.net","subject":"Re: [RFE] Please add a standard ref object to releases","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-11-01T13:09:13Z","receivedAt":"2018-11-01T13:09:19Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Nov 01 2018, Nicolas Mailhot wrote:\n\n> Le jeudi 01 novembre 2018 à 12:15 +0100, Ævar Arnfjörð Bjarmason a\n> écrit :\n>>\n>> For both this and your other report, it would be helpful if you\n>> describe\n>> in concrete terms (with examples of git commands, or UI etc.) what git\n>> commands do now, what's wrong with it, and some sketch of what you\n>> expect an alternate interface to look like.\n>>\n>> As for this report: I know this area of git quite well, but I still\n>> have no idea quite what you're asking for.\n>\n> It says a lot that you claim to know this area of git quite well, but\n> have no understanding how it is (mis)used on github/gitlab/bitbucket/etc\n> by people who actually try to use git.\n\nYeah I think it says a lot about how vague your proposal is.\n\nYou're the one trying to ostensibly file some sort of bug report or\nfeature request, it's up to you to explain the problem in detail.\n\n> I’m just asking that when a project releases “x.y.z”\n>\n> 1. there was a standard git command available to it to create \"the\n> release “x.y.z”\" ref\n\nAnd would these also be annotated tags, or are you proposing that we add\na new \"release\" object type in addition to blob/tree/commit/tag? If so\nwhat would that look like?\n\n> 2. there was a git syntax to say \"the release “x.y.z”\" ref in all git\n> commands that manipulate refs\n\nWhat do you mean \"git syntaX\"? The rev-parse syntax (see 'git help\nrev-parse`) or something else?\n\n> 3. that this \"release “x.y.z”\" ref could be used in all the \"download\n> release “x.y.z”\" on GitLab/GitHub, etc\n\nSo instead of offering a download of annotated tags as they do now, see\nhttps://github.com/git/git/releases and\nhttps://gitlab.com/git-vcs/git/tags they'd offer a download of whatevr\nthis new thing is?\n\n> 4. that there was no fuziness or human interpretation involved into\n> converting \"x.y.z\" into the syntax used to select \"release “x.y.z”\" in\n> git commands\n\nSo since we'd store this in refs/* somewhere since it's (presumably)\nnamed named ref of some sort, you're suggesting that this thing be\nexempt from the DWYM name resolution of refs, e.g. us resolving \"master\"\nto \"refs/heads/master\" or v1.0 to \"refs/tags/v1.0\" (but as you note\nthat's ambiguous).\n\nSo you'd always need to do e.g. \"git show refs/releases/v1.0\"?\n\n> 5. there was no ambiguïty in this syntax that led to the selection of\n> things that are not \"release\" refs and just look like them\n\nI don't know what you mean by \"syntax\" and \"selection\" in this context.\n\n> And **not** the current situation where there are no official \"release\n> ref\" objects and \"just map release names to tags, mapping recipe is left\n> to the reader\". Because everyone invents its own recipe and the result\n> does not work.\n\nI'm still entirely unclear about \"does not work\" here.\n\n> And no, vfoo is not a form of release ref, because v1 can be a branch,\n> not a tag, version3 tag is not the release ersion3, etc (real-world\n> examples I can provide links if you don't believe me). You can’t let\n> things undefined as they are now because git users as a whole are making\n> a mess of things without tooling help.\n\nThis seems like another complaint about the ref ambiguities. That's fair\nenough, but how is that per-se related to this proposal? We also have\nambiguity now between \"master\" tags and branches.\n\n>> If we assume this is a good idea, how do you imagine this would work\n>> once you don't just have two levels (random labels v.s. \"real\"\n>> releases)\n>> but three or more (random labels v.s. \"real\" releases v.s. \"LTS\"\n>> releases, ....)?\n>\n> IMHO you’re over-engineering things there. There is a need for separate\n> release refs, as evidenced by the fact every major git web frontend had\n> to separate them from normal tags in its UI. I'm not aware of the same\n> thing for LTS or whatever.\n>\n> Of course implementing generic namespacing, would be a way to get a\n> separate release namespace. As long as this release namespace is\n> unambiguously defined at the git level without replaying the 'just\n> invent your own tag recipe' mess at another level.\n\nIt's not over-engineering. Right now we have a hierarchical namespace\nfor tags and branches, so if you want N levels deep or whatever you do\nthat with prefixes or subdirectories, and there's plenty of examples of\nthat in the wild. E.g. tags created for hacking, QA, pre-release,\nrelease, LTS etc.\n\nWhereas if you're proposing some mechanism that we draw a line somewhere\nin that flow and say \"now tag/mark/release stuff as different sorts of\nobjects\" it's up to you to convince us why that's a realistic view of\nthe world.\n"},{"id":"362190","messageId":"f188d25c4ae49bd234a52a9200a2caefbb65191c.camel@laposte.net","threadId":"49730","inReplyTo":"87y3adj66e.fsf@evledraar.gmail.com","subject":"Re: [RFE] Please add a standard ref object to releases","fromName":"Nicolas Mailhot","fromEmail":"nicolas.mailhot@laposte.net","sentAt":"2018-11-01T14:32:13Z","receivedAt":"2018-11-01T14:32:18Z","isPatch":false,"sender":{"key":"nicolas.mailhot@laposte.net","avatar":null},"body":"Le jeudi 01 novembre 2018 à 14:09 +0100, Ævar Arnfjörð Bjarmason a\né\n\n> You're the one trying to ostensibly file some sort of bug report or\n> feature request, it's up to you to explain the problem in detail.\n> \n> > I’m just asking that when a project releases “x.y.z”\n> > \n> > 1. there was a standard git command available to it to create \"the\n> > release “x.y.z”\" ref\n> \n> And would these also be annotated tags, or are you proposing that we\n> add\n> a new \"release\" object type in addition to blob/tree/commit/tag? If so\n> what would that look like?\n\nIt could have been done via annotated tags if release annotations, and\nthe associated porcelain, had been clearly defined and documented from\nthe start up. The technical implementation would have been fuzzy but\nstrong convention would have compensated the fuzziness.\n\nThis ship sailed a long time ago, at this point not only you do not have\nconvention to help you but you have all the custom workarounds people\ninvented to get by to overcome. So, I doubt anything short of a separate\nobject can work now (but I'd be delighted to be proven wrong).\n\nOf course as long as the porcelain is unambiguous most git users won't\ncare how it is stored by git.\n\n> > 2. there was a git syntax to say \"the release “x.y.z”\" ref in all\n> > git\n> > commands that manipulate refs\n> \n> What do you mean \"git syntaX\"? The rev-parse syntax (see 'git help\n> rev-parse`) or something else?\n\nI mean that:\n– I give you a repo name and its URL.\n– I give you a release name such as 1.2.3.4\n 1. write the command to checkout this release\n 2. write  the command to diff this release with the latest master\ncommit\n 3. write  the command to declare that master is release 1.2.3.4.5\netc\n\nYou’re forbidden to look at the content of the repo to browse its tags\nand branches and use human logic to guess human convention. You can only\nbe sure that 1.2.3.4 is the actual release chosen by the project owner\nas stated in its release notes.\n\nAnd then try to do it for Apache Thrift 0.11 and git 2.19.0\nhttps://github.com/apache/thrift/\nand\nhttps://github.com/git/git\n\n(see, I’m nice, I didn’t even fed you Gitlab vs GitHub differences, or\nsome project released by an illustrious anonymous)\n\nOr alternatively, try\ngnome-calendar 3.28.0.1 and git 2.18.1\n\nThey’re on\nhttps://gitlab.com/git-vcs/git/\nhttps://gitlab.gnome.org/GNOME/gnome-calendar/\n\nso, latest version of Gitlab for both of them.\n\n> > 3. that this \"release “x.y.z”\" ref could be used in all the\n> > \"download\n> > release “x.y.z”\" on GitLab/GitHub, etc\n> \n> So instead of offering a download of annotated tags as they do now,\n> see\n> https://github.com/git/git/releases and\n> https://gitlab.com/git-vcs/git/tags they'd offer a download of whatevr\n> this new thing is?\n\nSo they could build a\nhttps://github.com/git/git/releases/<x.y.z>/\nor\nhttps://gitlab.com/git-vcs/git/releases/<x.y.z>/\n\nand it would just give you the correct release archive, for example. Not\ndifficult for them to do as long as the mapping from release name “x.y.z\n” to git repo object is well defined.\n\n> > 4. that there was no fuziness or human interpretation involved into\n> > converting \"x.y.z\" into the syntax used to select \"release “x.y.z”\"\n> > in git commands\n> \n> So since we'd store this in refs/* somewhere since it's (presumably)\n> named named ref of some sort, you're suggesting that this thing be\n> exempt from the DWYM name resolution of refs, e.g. us resolving\n> \"master\"\n> to \"refs/heads/master\" or v1.0 to \"refs/tags/v1.0\" (but as you note\n> that's ambiguous).\n> \n> So you'd always need to do e.g. \"git show refs/releases/v1.0\"?\n\nIt would be nice to have something shorter to type, but the root problem\nis the ambiguity and lack of definition of current git releases, so\nsomething unambiguous trumps something short, but fuzzy.\n\nAnd, in your example, the v is unnecessary.\n\nThe v was just shoved in tag names to try to distinguish releases. It\ndidn’t work. It would have worked if git had blocked any tag starting\nwith v that was not a release tag, and forbidden branches with a v name.\nBut that ship sailed a long time ago.\n\nYears of workarounds have brainwashed you into thinking the v is\nnecessary. But, it does not exist outside git land. Or even in the\nrelease notes filenames git releases itself\nhttps://github.com/git/git/tree/master/Documentation/RelNotes\n\n(Much as I hate the v thing, I could have lived with it if it was\nconsistently applied by git projects. It isn’t)\n\n> Whereas if you're proposing some mechanism that we draw a line\n> somewhere\n> in that flow and say \"now tag/mark/release stuff as different sorts of\n> objects\" it's up to you to convince us why that's a realistic view of\n> the world.\n\nIf it was not a realistic view of the world github wouln’t have had to\ndefine separate sections for releases and tags in its UI.\n\nIf tags and release were the same thing one could take random git\nprojects on github or gitlab and apply release rules like semver to\ntheir tags. Even projects that use semver do not have semver-only tags,\nand even their semver tags cant'd be semvered as-is because of random\ninjections of prefixes like v or version.\n\nRegards,\n\n-- \nNicolas Mailhot\n\n"}]}