{"thread":{"id":"47306","subject":"RE: Re: Unify annotated and non-annotated tags","startedAt":"2017-11-23T15:08:17Z","lastAt":"2017-12-24T12:33:57Z","messageCount":10,"participants":["Randall S. Becker","Thomas Braun","anatoly techtonik","Ævar Arnfjörð Bjarmason","Philip Oakley","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"333384","messageId":"003c01d3646c$df78fc50$9e6af4f0$@nexbridge.com","threadId":"47306","inReplyTo":"201711231458.vANEwUMK048049@elephants.elehost.com","subject":"RE: Re: Unify annotated and non-annotated tags","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2017-11-23T15:08:07Z","receivedAt":"2017-11-23T15:08:17Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote\n>Subject: Re: Unify annotated and non-annotated tags \n>On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano wrote:\n>> Igor Djordjevic writes:\n>>\n>>> If you would like to mimic output of \"git show-ref\", repeating\n>>> commits for each tag pointing to it and showing full tag name as\n>>> well, you could do something like this, for example:\n>>>\n>>> for tag in $(git for-each-ref --format=\"%(refname)\" refs/tags)\n>>> do\n>>> printf '%s %s\\n' \"$(git rev-parse $tag^0)\" \"$tag\"\n>>> done\n>>>\n>>>\n>>> Hope that helps a bit.\n>>\n>> If you use for-each-ref's --format option, you could do something\n>> like (pardon a long line):\n>>\n>> git for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) %(refname)' refs/tags\n>>\n>> without any loop, I would think.\n>Thanks. That helps.\n>So my proposal is to get rid of non-annotated tags, so to get all\n>tags with commits that they point to, one would use:\n>git for-each-ref --format='%(*objectname) %(refname)' refs/tags>\n>For so-called non-annotated tags just leave the message empty.\n>I don't see why anyone would need non-annotated tags though.\n\nI have seen non-annotated tags used in automations (not necessarily well written ones) that create tags as a record of automation activity. I am not sure we should be writing off the concept of unannotated tags entirely. This may cause breakage based on existing expectations of how tags work at present. My take is that tags should include whodunnit, even if it's just the version of the automation being used, but I don't always get to have my wishes fulfilled. In essence, whatever behaviour a non-annotated tag has now may need to be emulated in future even if reconciliation happens. An option to preserve empty tag compatibility with pre-2.16 behaviour, perhaps? Sadly, I cannot supply examples of this usage based on a human memory page-fault and NDAs.\n\nCheers,\nRandall\n\n-- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000)\n-- In my real life, I talk too much.\n\n\n\n"},{"id":"333393","messageId":"f189258d-5709-d236-ff58-5653edc57eb6@virtuell-zuhause.de","threadId":"47306","inReplyTo":"003c01d3646c$df78fc50$9e6af4f0$@nexbridge.com","subject":"Re: Unify annotated and non-annotated tags","fromName":"Thomas Braun","fromEmail":"thomas.braun@virtuell-zuhause.de","sentAt":"2017-11-23T21:24:13Z","receivedAt":"2017-11-23T21:24:29Z","isPatch":false,"sender":{"key":"thomas.braun@virtuell-zuhause.de","avatar":"https://avatars.githubusercontent.com/u/1185677?v=4"},"body":"Am 23.11.2017 um 16:08 schrieb Randall S. Becker:\n\n[...]\n\n>> So my proposal is to get rid of non-annotated tags, so to get all\n>> tags with commits that they point to, one would use:\n>> git for-each-ref --format='%(*objectname) %(refname)' refs/tags>\n>> For so-called non-annotated tags just leave the message empty.\n>> I don't see why anyone would need non-annotated tags though.\n\nI'm using exclusively non-annotated tags. Why? Because that is the\ndefault of \"git tag\" and I also, until now, never needed more than\ngiving a commit a \"name\".\n\nMany annotated tag messages just repeat the tag name itself, so the\nmessage seems quite redundant to me.\n\nJust my 2 cents,\nThomas\n"},{"id":"333426","messageId":"CAPkN8xJBWRs-2DxViBACLKzAbD1_EBA2MvmWVZmWgL+Sg72znw@mail.gmail.com","threadId":"47306","inReplyTo":"003c01d3646c$df78fc50$9e6af4f0$@nexbridge.com","subject":"Re: Re: Unify annotated and non-annotated tags","fromName":"anatoly techtonik","fromEmail":"techtonik@gmail.com","sentAt":"2017-11-24T09:52:02Z","receivedAt":"2017-11-24T09:52:29Z","isPatch":false,"sender":{"key":"techtonik@gmail.com","avatar":"https://gravatar.com/avatar/94c82f2698c78dcbc926e549dcfcfae48be4e89c6959287fca063cd461b75af7?d=mp&s=160"},"body":"On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker\n wrote:\n> On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote\n>>Subject: Re: Unify annotated and non-annotated tags\n>>On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano wrote:\n>>> Igor Djordjevic writes:\n>>>\n>>>> If you would like to mimic output of \"git show-ref\", repeating\n>>>> commits for each tag pointing to it and showing full tag name as\n>>>> well, you could do something like this, for example:\n>>>>\n>>>> for tag in $(git for-each-ref --format=\"%(refname)\" refs/tags)\n>>>> do\n>>>> printf '%s %s\\n' \"$(git rev-parse $tag^0)\" \"$tag\"\n>>>> done\n>>>>\n>>>>\n>>>> Hope that helps a bit.\n>>>\n>>> If you use for-each-ref's --format option, you could do something\n>>> like (pardon a long line):\n>>>\n>>> git for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) %(refname)' refs/tags\n>>>\n>>> without any loop, I would think.\n>>Thanks. That helps.\n>>So my proposal is to get rid of non-annotated tags, so to get all\n>>tags with commits that they point to, one would use:\n>>git for-each-ref --format='%(*objectname) %(refname)' refs/tags>\n>>For so-called non-annotated tags just leave the message empty.\n>>I don't see why anyone would need non-annotated tags though.\n>\n> I have seen non-annotated tags used in automations (not necessarily well written ones) that create tags as a record of automation activity. I am not sure we should be writing off the concept of unannotated tags entirely. This may cause breakage based on existing expectations of how tags work at present. My take is that tags should include whodunnit, even if it's just the version of the automation being used, but I don't always get to have my wishes fulfilled. In essence, whatever behaviour a non-annotated tag has now may need to be emulated in future even if reconciliation happens. An option to preserve empty tag compatibility with pre-2.16 behaviour, perhaps? Sadly, I cannot supply examples of this usage based on a human memory page-fault and NDAs.\n\nAre there any windows for backward compatibility breaks, or git is\ndoomed to preserve it forever?\nAutomation without support won't survive for long, and people who rely\non that, like Chromium team, usually hard set the version used.\n-- \nanatoly t.\n"},{"id":"333427","messageId":"CACBZZX4SM45hgA=PW0MEP9Ea0OG_8OTb5U7JCOX7xnd=hT5n3A@mail.gmail.com","threadId":"47306","inReplyTo":"CAPkN8xJBWRs-2DxViBACLKzAbD1_EBA2MvmWVZmWgL+Sg72znw@mail.gmail.com","subject":"Re: Re: Unify annotated and non-annotated tags","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-11-24T10:24:08Z","receivedAt":"2017-11-24T10:24:35Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Nov 24, 2017 at 10:52 AM, anatoly techtonik wrote:\n> On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker\n> wrote:\n>> On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote\n>>>Subject: Re: Unify annotated and non-annotated tags\n>>>On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano wrote:\n>>>> Igor Djordjevic writes:\n>>>>\n>>>>> If you would like to mimic output of \"git show-ref\", repeating\n>>>>> commits for each tag pointing to it and showing full tag name as\n>>>>> well, you could do something like this, for example:\n>>>>>\n>>>>> for tag in $(git for-each-ref --format=\"%(refname)\" refs/tags)\n>>>>> do\n>>>>> printf '%s %s\\n' \"$(git rev-parse $tag^0)\" \"$tag\"\n>>>>> done\n>>>>>\n>>>>>\n>>>>> Hope that helps a bit.\n>>>>\n>>>> If you use for-each-ref's --format option, you could do something\n>>>> like (pardon a long line):\n>>>>\n>>>> git for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) %(refname)' refs/tags\n>>>>\n>>>> without any loop, I would think.\n>>>Thanks. That helps.\n>>>So my proposal is to get rid of non-annotated tags, so to get all\n>>>tags with commits that they point to, one would use:\n>>>git for-each-ref --format='%(*objectname) %(refname)' refs/tags>\n>>>For so-called non-annotated tags just leave the message empty.\n>>>I don't see why anyone would need non-annotated tags though.\n>>\n>> I have seen non-annotated tags used in automations (not necessarily well written ones) that create tags as a record of automation activity. I am not sure we should be writing off the concept of unannotated tags entirely. This may cause breakage based on existing expectations of how tags work at present. My take is that tags should include whodunnit, even if it's just the version of the automation being used, but I don't always get to have my wishes fulfilled. In essence, whatever behaviour a non-annotated tag has now may need to be emulated in future even if reconciliation happens. An option to preserve empty tag compatibility with pre-2.16 behaviour, perhaps? Sadly, I cannot supply examples of this usage based on a human memory page-fault and NDAs.\n>\n> Are there any windows for backward compatibility breaks, or git is\n> doomed to preserve it forever?\n> Automation without support won't survive for long, and people who rely\n> on that, like Chromium team, usually hard set the version used.\n\nGit is not doomed to preserve anything forever. We've gradually broken\nbackwards compatibility for a few core things like these.\n\nHowever, just as a bystander reading this thread I haven't seen any\ncompelling reason for why these should be removed. You initially had\nquestions about how to extract info about them, which you got answers\nto.\n\nSo what reasons remain for why they need to be removed?\n"},{"id":"333444","messageId":"000601d3652e$11e38220$35aa8660$@nexbridge.com","threadId":"47306","inReplyTo":"CAPkN8xJBWRs-2DxViBACLKzAbD1_EBA2MvmWVZmWgL+Sg72znw@mail.gmail.com","subject":"RE: Re: Unify annotated and non-annotated tags","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2017-11-24T14:11:01Z","receivedAt":"2017-11-24T14:11:20Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On November 24, 2017 4:52 AM anatoly techtonik wrote:\n>On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker wrote:\n>> On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote\n>>>Subject: Re: Unify annotated and non-annotated tags On Sat, Nov 11, \n>>>2017 at 5:06 AM, Junio C Hamano wrote:\n>>>> Igor Djordjevic writes:\n>>>>\n>>>>> If you would like to mimic output of \"git show-ref\", repeating \n>>>>> commits for each tag pointing to it and showing full tag name as \n>>>>> well, you could do something like this, for example:\n>>>>>\n>>>>> for tag in $(git for-each-ref --format=\"%(refname)\" refs/tags)\n>>>>> do\n>>>>> printf '%s %s\\n' \"$(git rev-parse $tag^0)\" \"$tag\"\n>>>>> done\n>>>>>\n>>>>>\n>>>>> Hope that helps a bit.\n>>>>\n>>>> If you use for-each-ref's --format option, you could do something \n>>>> like (pardon a long line):\n>>>>\n>>>> git for-each-ref \n>>>> --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectnam\n>>>> e)%(end) %(refname)' refs/tags\n>>>>\n>>>> without any loop, I would think.\n>>>Thanks. That helps.\n>>>So my proposal is to get rid of non-annotated tags, so to get all tags \n>>>with commits that they point to, one would use:\n>>>git for-each-ref --format='%(*objectname) %(refname)' refs/tags> For \n>>>so-called non-annotated tags just leave the message empty.\n>>>I don't see why anyone would need non-annotated tags though.\n>>\n>> I have seen non-annotated tags used in automations (not necessarily well written ones) that\n>> create tags as a record of automation activity. I am not sure we should be writing off the\n>> concept of unannotated tags entirely. This may cause breakage based on existing expectations\n>> of how tags work at present. My take is that tags should include whodunnit, even if it's just the\n>> version of the automation being used, but I don't always get to have my wishes fulfilled. In\n>> essence, whatever behaviour a non-annotated tag has now may need to be emulated in\n>> future even if reconciliation happens. An option to preserve empty tag compatibility with\n>> pre-2.16 behaviour, perhaps? Sadly, I cannot supply examples of this usage based on a\n>> human memory page-fault and NDAs.\n>Are there any windows for backward compatibility breaks, or git is doomed to preserve it forever?\n>Automation without support won't survive for long, and people who rely on that,\n>like Chromium team, usually hard set the version used.\n\nJust pointing out that changing the semantics of a basic data item in git may have unintended consequences.\n\n"},{"id":"333971","messageId":"CAPkN8xKDQrf+LMpj9GHw9n_crJ1UUwq7Zek+Z1dgQ0n2Jz5U6g@mail.gmail.com","threadId":"47306","inReplyTo":"CACBZZX4SM45hgA=PW0MEP9Ea0OG_8OTb5U7JCOX7xnd=hT5n3A@mail.gmail.com","subject":"Re: Re: Unify annotated and non-annotated tags","fromName":"anatoly techtonik","fromEmail":"techtonik@gmail.com","sentAt":"2017-12-02T21:26:59Z","receivedAt":"2017-12-02T21:27:26Z","isPatch":false,"sender":{"key":"techtonik@gmail.com","avatar":"https://gravatar.com/avatar/94c82f2698c78dcbc926e549dcfcfae48be4e89c6959287fca063cd461b75af7?d=mp&s=160"},"body":"On Fri, Nov 24, 2017 at 1:24 PM, Ævar Arnfjörð Bjarmason\n wrote:\n> On Fri, Nov 24, 2017 at 10:52 AM, anatoly techtonik wrote:\n>> On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker\n>> wrote:\n>>> On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote\n>>>>Subject: Re: Unify annotated and non-annotated tags\n>>>>On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano wrote:\n>>>>> Igor Djordjevic writes:\n>>>>>\n>>>>>> If you would like to mimic output of \"git show-ref\", repeating\n>>>>>> commits for each tag pointing to it and showing full tag name as\n>>>>>> well, you could do something like this, for example:\n>>>>>>\n>>>>>> for tag in $(git for-each-ref --format=\"%(refname)\" refs/tags)\n>>>>>> do\n>>>>>> printf '%s %s\\n' \"$(git rev-parse $tag^0)\" \"$tag\"\n>>>>>> done\n>>>>>>\n>>>>>>\n>>>>>> Hope that helps a bit.\n>>>>>\n>>>>> If you use for-each-ref's --format option, you could do something\n>>>>> like (pardon a long line):\n>>>>>\n>>>>> git for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) %(refname)' refs/tags\n>>>>>\n>>>>> without any loop, I would think.\n>>>>Thanks. That helps.\n>>>>So my proposal is to get rid of non-annotated tags, so to get all\n>>>>tags with commits that they point to, one would use:\n>>>>git for-each-ref --format='%(*objectname) %(refname)' refs/tags>\n>>>>For so-called non-annotated tags just leave the message empty.\n>>>>I don't see why anyone would need non-annotated tags though.\n>>>\n>>> I have seen non-annotated tags used in automations (not necessarily well written ones) that create tags as a record of automation activity. I am not sure we should be writing off the concept of unannotated tags entirely. This may cause breakage based on existing expectations of how tags work at present. My take is that tags should include whodunnit, even if it's just the version of the automation being used, but I don't always get to have my wishes fulfilled. In essence, whatever behaviour a non-annotated tag has now may need to be emulated in future even if reconciliation happens. An option to preserve empty tag compatibility with pre-2.16 behaviour, perhaps? Sadly, I cannot supply examples of this usage based on a human memory page-fault and NDAs.\n>>\n>> Are there any windows for backward compatibility breaks, or git is\n>> doomed to preserve it forever?\n>> Automation without support won't survive for long, and people who rely\n>> on that, like Chromium team, usually hard set the version used.\n>\n> Git is not doomed to preserve anything forever. We've gradually broken\n> backwards compatibility for a few core things like these.\n>\n> However, just as a bystander reading this thread I haven't seen any\n> compelling reason for why these should be removed. You initially had\n> questions about how to extract info about them, which you got answers\n> to.\n>\n> So what reasons remain for why they need to be removed?\n\nTo reduce complexity and prior knowledge when dealing with Git tags.\n\nFor example, http://readthedocs.io/ site contains a lot of broken\n\"Edit on GitHub\" links, for example - http://git-memo.readthedocs.io/en/stable/\n\nAnd it appeared that the reason for that is discrepancy between git\nannotated and non-annotated tags. The pull request that fixes the issue\nafter it was researched and understood is simple\nhttps://github.com/rtfd/readthedocs.org/pull/3302\n\nHowever, while looking through linked issues and PRs, one can try to\nimagine how many days it took for people to come up with the solution,\nwhich came from this thread.\n-- \nanatoly t.\n"},{"id":"333972","messageId":"FF34D4C2058D44E990BF149F3AB1E010@PhilipOakley","threadId":"47306","inReplyTo":"CAPkN8xKDQrf+LMpj9GHw9n_crJ1UUwq7Zek+Z1dgQ0n2Jz5U6g@mail.gmail.com","subject":"Re: Re: Unify annotated and non-annotated tags","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2017-12-02T22:26:04Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"anatoly techtonik\" \n\ncomment at end - Philip\n\nOn Fri, Nov 24, 2017 at 1:24 PM, Ævar Arnfjörð Bjarmason\n wrote:\n> On Fri, Nov 24, 2017 at 10:52 AM, anatoly techtonik \n> wrote:\n>> On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker\n>> wrote:\n>>> On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote\n>>>>Subject: Re: Unify annotated and non-annotated tags\n>>>>On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano \n>>>>wrote:\n>>>>> Igor Djordjevic writes:\n>>>>>\n>>>>>> If you would like to mimic output of \"git show-ref\", repeating\n>>>>>> commits for each tag pointing to it and showing full tag name as\n>>>>>> well, you could do something like this, for example:\n>>>>>>\n>>>>>> for tag in $(git for-each-ref --format=\"%(refname)\" refs/tags)\n>>>>>> do\n>>>>>> printf '%s %s\\n' \"$(git rev-parse $tag^0)\" \"$tag\"\n>>>>>> done\n>>>>>>\n>>>>>>\n>>>>>> Hope that helps a bit.\n>>>>>\n>>>>> If you use for-each-ref's --format option, you could do something\n>>>>> like (pardon a long line):\n>>>>>\n>>>>> git \n>>>>> for-each-ref --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end) \n>>>>> %(refname)' refs/tags\n>>>>>\n>>>>> without any loop, I would think.\n>>>>Thanks. That helps.\n>>>>So my proposal is to get rid of non-annotated tags, so to get all\n>>>>tags with commits that they point to, one would use:\n>>>>git for-each-ref --format='%(*objectname) %(refname)' refs/tags>\n>>>>For so-called non-annotated tags just leave the message empty.\n>>>>I don't see why anyone would need non-annotated tags though.\n>>>\n>>> I have seen non-annotated tags used in automations (not necessarily well \n>>> written ones) that create tags as a record of automation activity. I am \n>>> not sure we should be writing off the concept of unannotated tags \n>>> entirely. This may cause breakage based on existing expectations of how \n>>> tags work at present. My take is that tags should include whodunnit, \n>>> even if it's just the version of the automation being used, but I don't \n>>> always get to have my wishes fulfilled. In essence, whatever behaviour a \n>>> non-annotated tag has now may need to be emulated in future even if \n>>> reconciliation happens. An option to preserve empty tag compatibility \n>>> with pre-2.16 behaviour, perhaps? Sadly, I cannot supply examples of \n>>> this usage based on a human memory page-fault and NDAs.\n>>\n>> Are there any windows for backward compatibility breaks, or git is\n>> doomed to preserve it forever?\n>> Automation without support won't survive for long, and people who rely\n>> on that, like Chromium team, usually hard set the version used.\n>\n> Git is not doomed to preserve anything forever. We've gradually broken\n> backwards compatibility for a few core things like these.\n>\n> However, just as a bystander reading this thread I haven't seen any\n> compelling reason for why these should be removed. You initially had\n> questions about how to extract info about them, which you got answers\n> to.\n>\n> So what reasons remain for why they need to be removed?\n\nTo reduce complexity and prior knowledge when dealing with Git tags.\n\nFor example, http://readthedocs.io/ site contains a lot of broken\n\"Edit on GitHub\" links, for example - \nhttp://git-memo.readthedocs.io/en/stable/\n\nAnd it appeared that the reason for that is discrepancy between git\nannotated and non-annotated tags. The pull request that fixes the issue\nafter it was researched and understood is simple\nhttps://github.com/rtfd/readthedocs.org/pull/3302\n\nHowever, while looking through linked issues and PRs, one can try to\nimagine how many days it took for people to come up with the solution,\nwhich came from this thread.\n-- \nanatoly t.\n\n>>>>>>>\n\nSo if I understand correctly, the hope is that `git show-ref --tags` could \nget an alternate option `--all-tags` [proper option name required...] such \nthat the user would not have to develop the rather over the complicated \nexpression that used a newish capability of a different command.\n\nWould that be right?\n\nOr at least update the man page docs to clarify the annotated vs \nnon-annotated tags issue (many SO questions!).\n\nAnd indicate if the --dereference and/or --hash options would do the \ntrick! - maybe the \"^{}\" appended would be part of the problem (and need \nthat new option \"--objectreference\" ).\n\nPhilip \n\n"},{"id":"333988","messageId":"xmqqa7z0jqzj.fsf@gitster.mtv.corp.google.com","threadId":"47306","inReplyTo":"CAPkN8xKDQrf+LMpj9GHw9n_crJ1UUwq7Zek+Z1dgQ0n2Jz5U6g@mail.gmail.com","subject":"Re: Unify annotated and non-annotated tags","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-12-03T05:54:40Z","receivedAt":"2017-12-03T05:54:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"anatoly techtonik writes:\n\n>> Git is not doomed to preserve anything forever. We've gradually broken\n>> backwards compatibility for a few core things like these.\n>>\n>> However, just as a bystander reading this thread I haven't seen any\n>> compelling reason for why these should be removed. You initially had\n>> questions about how to extract info about them, which you got answers\n>> to.\n>>\n>> So what reasons remain for why they need to be removed?\n>\n> To reduce complexity and prior knowledge when dealing with Git tags.\n\nThen you are barking up a wrong tree, I would have to say. If you\ndo not think non-annotated tags are serving any good purpose in the\ncontext of _a_ project you are involved in and making your life\nmiserable because some tags are and other tags are not annotated,\nsuggest to _that_ project to refrain from using non-annotated tags.\n\nProjects that do use non-annotated tags have chosen to use them for\nreasons of their own. It may be that these tags could be annotated\ntags instead for some projects, and depending on their tooling there\nmight be no downside in switching. Or they may have chosen to use\nnon-annotated tags for reasons that you do not know.\n\n"},{"id":"335225","messageId":"CAPkN8xL1tUszvMuwwrc1ym6B6R5TzE4G9jKQ08oY2O_VPc8K_w@mail.gmail.com","threadId":"47306","inReplyTo":"FF34D4C2058D44E990BF149F3AB1E010@PhilipOakley","subject":"Re: Re: Unify annotated and non-annotated tags","fromName":"anatoly techtonik","fromEmail":"techtonik@gmail.com","sentAt":"2017-12-23T13:41:37Z","receivedAt":"2017-12-23T13:45:14Z","isPatch":false,"sender":{"key":"techtonik@gmail.com","avatar":"https://gravatar.com/avatar/94c82f2698c78dcbc926e549dcfcfae48be4e89c6959287fca063cd461b75af7?d=mp&s=160"},"body":"On Sun, Dec 3, 2017 at 1:25 AM, Philip Oakley wrote:\n> From: \"anatoly techtonik\" \n>\n> comment at end - Philip\n>\n>\n> On Fri, Nov 24, 2017 at 1:24 PM, Ævar Arnfjörð Bjarmason\n> wrote:\n>>\n>> On Fri, Nov 24, 2017 at 10:52 AM, anatoly techtonik \n>> wrote:\n>>>\n>>> On Thu, Nov 23, 2017 at 6:08 PM, Randall S. Becker\n>>> wrote:\n>>>>\n>>>> On 2017-11-23 02:31 (GMT-05:00) anatoly techtonik wrote\n>>>>>\n>>>>> Subject: Re: Unify annotated and non-annotated tags\n>>>>> On Sat, Nov 11, 2017 at 5:06 AM, Junio C Hamano \n>>>>> wrote:\n>>>>>>\n>>>>>> Igor Djordjevic writes:\n>>>>>>\n>>>>>>> If you would like to mimic output of \"git show-ref\", repeating\n>>>>>>> commits for each tag pointing to it and showing full tag name as\n>>>>>>> well, you could do something like this, for example:\n>>>>>>>\n>>>>>>> for tag in $(git for-each-ref --format=\"%(refname)\" refs/tags)\n>>>>>>> do\n>>>>>>> printf '%s %s\\n' \"$(git rev-parse $tag^0)\" \"$tag\"\n>>>>>>> done\n>>>>>>>\n>>>>>>>\n>>>>>>> Hope that helps a bit.\n>>>>>>\n>>>>>>\n>>>>>> If you use for-each-ref's --format option, you could do something\n>>>>>> like (pardon a long line):\n>>>>>>\n>>>>>> git for-each-ref\n>>>>>> --format='%(if)%(*objectname)%(then)%(*objectname)%(else)%(objectname)%(end)\n>>>>>> %(refname)' refs/tags\n>>>>>>\n>>>>>> without any loop, I would think.\n>>>>>\n>>>>> Thanks. That helps.\n>>>>> So my proposal is to get rid of non-annotated tags, so to get all\n>>>>> tags with commits that they point to, one would use:\n>>>>> git for-each-ref --format='%(*objectname) %(refname)' refs/tags>\n>>>>> For so-called non-annotated tags just leave the message empty.\n>>>>> I don't see why anyone would need non-annotated tags though.\n>>>>\n>>>>\n>>>> I have seen non-annotated tags used in automations (not necessarily well\n>>>> written ones) that create tags as a record of automation activity. I am not\n>>>> sure we should be writing off the concept of unannotated tags entirely. This\n>>>> may cause breakage based on existing expectations of how tags work at\n>>>> present. My take is that tags should include whodunnit, even if it's just\n>>>> the version of the automation being used, but I don't always get to have my\n>>>> wishes fulfilled. In essence, whatever behaviour a non-annotated tag has now\n>>>> may need to be emulated in future even if reconciliation happens. An option\n>>>> to preserve empty tag compatibility with pre-2.16 behaviour, perhaps? Sadly,\n>>>> I cannot supply examples of this usage based on a human memory page-fault\n>>>> and NDAs.\n>>>\n>>>\n>>> Are there any windows for backward compatibility breaks, or git is\n>>> doomed to preserve it forever?\n>>> Automation without support won't survive for long, and people who rely\n>>> on that, like Chromium team, usually hard set the version used.\n>>\n>>\n>> Git is not doomed to preserve anything forever. We've gradually broken\n>> backwards compatibility for a few core things like these.\n>>\n>> However, just as a bystander reading this thread I haven't seen any\n>> compelling reason for why these should be removed. You initially had\n>> questions about how to extract info about them, which you got answers\n>> to.\n>>\n>> So what reasons remain for why they need to be removed?\n>\n>\n> To reduce complexity and prior knowledge when dealing with Git tags.\n>\n> For example, http://readthedocs.io/ site contains a lot of broken\n> \"Edit on GitHub\" links, for example -\n> http://git-memo.readthedocs.io/en/stable/\n>\n> And it appeared that the reason for that is discrepancy between git\n> annotated and non-annotated tags. The pull request that fixes the issue\n> after it was researched and understood is simple\n> https://github.com/rtfd/readthedocs.org/pull/3302\n>\n> However, while looking through linked issues and PRs, one can try to\n> imagine how many days it took for people to come up with the solution,\n> which came from this thread.\n> --\n> anatoly t.\n>\n>>>>>>>>\n>\n> So if I understand correctly, the hope is that `git show-ref --tags` could\n> get an alternate option `--all-tags` [proper option name required...] such\n> that the user would not have to develop the rather over the complicated\n> expression that used a newish capability of a different command.\n>\n> Would that be right?\n\nThat's correct.\n\n> Or at least update the man page docs to clarify the annotated vs\n> non-annotated tags issue (many SO questions!).\n\nAre there stats how many users read man pages and what is their\nreading session length? I mean docs may not help much,\n\n> And indicate if the --dereference and/or --hash options would do the trick!\n> - maybe the \"^{}\" appended would be part of the problem (and need that new\n> option \"--objectreference\" ).\n\n--dereference would work if it didn't require extra processing.\nIt is hard to think about other option name that would give\ndesired result.\n\n-- \nanatoly t.\n"},{"id":"335255","messageId":"99FE6DCAB81A4510ACF961290988C094@PhilipOakley","threadId":"47306","inReplyTo":"CAPkN8xL1tUszvMuwwrc1ym6B6R5TzE4G9jKQ08oY2O_VPc8K_w@mail.gmail.com","subject":"Re: Re: Unify annotated and non-annotated tags","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2017-12-24T12:33:57Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"anatoly techtonik\" \n> From: Philip Oakley\n> > So if I understand correctly, the hope is that `git show-ref --tags` \n> > could\n> > get an alternate option `--all-tags` [proper option name required...] \n> > such\n> > that the user would not have to develop the rather over the complicated\n> > expression that used a newish capability of a different command.\n>\n> > Would that be right?\n\n> That's correct.\n\n> > Or at least update the man page docs to clarify the annotated vs\n> > non-annotated tags issue (many SO questions!).\n\n> Are there stats how many users read man pages and what is their\n> reading session length? I mean docs may not help much,\n\nThe \"reading the manual\" question is fairly well answered in the Human Error \nliterature in terms of clarity and effectiveness, and the normal human error \nrates (for interest search for \"Panko\" \"Spreadsheet errors\" [1]). Typical \nhuman error rate is 1%. Most pilot error ends up being, in part, caused by \nconfusing / incomplete manuals (i.e. we fail to support them).\n\nIf the manuals are the peak of perfection then they are well visited and the \nsupporting material is usually good. If manuals are a sprawling upland with \nbogs, fissure, islands of inaccessability, then they are rarely used.\n\nGit does suffer from having a lot of separate commands, which makes seeing \nthe woods for the trees difficult sometimes, especially as its core concepts \nare not always well understood.\n\nImproving the manuals (as reference material) will always help, even if the \ntrickle down effect is slow (made worse by alternate sources of error - \nStackoverflow and blogs... ;-)\n\n> > And indicate if the --dereference and/or --hash options would do the \n> > trick!\n> > - maybe the \"^{}\" appended would be part of the problem (and need that \n> > new\n> > option \"--objectreference\" ).\n\n> --dereference would work if it didn't require extra processing.\n> It is hard to think about other option name that would give\n> desired result.\n> ---\n> anatoly t.\n--\nPhilip\n\n[1] https://arxiv.org/abs/1602.02601 https://arxiv.org/pdf/1602.02601\n\"This paper reviews human cognition processes and shows first that humans \ncannot be error free no matter how hard they try, and second that our \nintuition about errors and how we can reduce them is based on appallingly \nbad knowledge.\" \n\n"}]}