{"thread":{"id":"54314","subject":"Differences in compound tag sorting between 2.27.0 and 2.21.0","startedAt":"2020-09-27T14:26:31Z","lastAt":"2020-09-27T20:35:31Z","messageCount":5,"participants":["Matthew Timothy Kennerly","Kyle Meyer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"406502","messageId":"CAKqNo6RJqp94uLMf8Biuo=ZvMZB9Mq6RRMrUgsLW4u1ks+mnOA@mail.gmail.com","threadId":"54314","inReplyTo":null,"subject":"Differences in compound tag sorting between 2.27.0 and 2.21.0","fromName":"Matthew Timothy Kennerly","fromEmail":"mtkennerly@gmail.com","sentAt":"2020-09-27T14:26:16Z","receivedAt":"2020-09-27T14:26:31Z","isPatch":false,"sender":{"key":"mtkennerly@gmail.com","avatar":null},"body":"Hello,\n\nI've run into a difference in the results for a compound tag sort\nbetween 2.21.0 and 2.27.0 (I believe also applies to 2.28.0), and I'm\nnot sure if it's an intentional difference or if there's still some\nway to achieve the old behavior with newer Git versions. For\nreference, I'm using Windows.\n\nI need to sort tags first by the date of the pointed commit, then by\nthe date of the tag creation when available (I understand that\nlightweight tags don't store their creation date, so multiple\nlightweight tags on a single commit may not sort consistently). Let me\ngive a concrete example.\n\nGiven a repository with this setup, using annotated tags:\n\n\ngit init\necho hi > foo.txt\ngit add .\ngit commit -m \"first\"\ngit tag v0.1.0 -m \"A\"\necho bye > foo.txt\ngit add .\ngit commit -m \"second\"\ngit tag v0.2.0 -m \"B\"\ngit tag v0.1.1 HEAD~1 -m \"C\"\n\n\nI get the desired sort results in 2.21.0:\n\n\n$ git tag --merged HEAD --sort -taggerdate --sort -committerdate\nv0.2.0\nv0.1.1\nv0.1.0\n\n\nHowever, in 2.27.0, the first listed tag is the tag that was most\nrecently created, rather than the one pointing to the newest commit:\n\n\n$ git tag --merged HEAD --sort -taggerdate --sort -committerdate\nv0.1.1\nv0.2.0\nv0.1.0\n\n\nSwapping the sort options in 2.27.0 does not affect the result,\nwhereas swapping them in 2.21.0 produces the same result as 2.27.0.\nThat makes it seem like 2.27.0 is ignoring the precedence order of the\nsort options.\n\nIf this is intentional, how can I achieve the desired sort order in\nnewer versions of Git?\n\nThanks,\n\nMTK\n"},{"id":"406504","messageId":"877dsffaq0.fsf@kyleam.com","threadId":"54314","inReplyTo":"CAKqNo6RJqp94uLMf8Biuo=ZvMZB9Mq6RRMrUgsLW4u1ks+mnOA@mail.gmail.com","subject":"Re: Differences in compound tag sorting between 2.27.0 and 2.21.0","fromName":"Kyle Meyer","fromEmail":"kyle@kyleam.com","sentAt":"2020-09-27T16:25:27Z","receivedAt":"2020-09-27T16:35:32Z","isPatch":false,"sender":{"key":"kyle@kyleam.com","avatar":"https://avatars.githubusercontent.com/u/1297788?v=4"},"body":"Matthew Timothy Kennerly writes:\n\n> Hello,\n>\n> I've run into a difference in the results for a compound tag sort\n> between 2.21.0 and 2.27.0 (I believe also applies to 2.28.0), and I'm\n> not sure if it's an intentional difference or if there's still some\n> way to achieve the old behavior with newer Git versions. For\n> reference, I'm using Windows.\n\nThis sounds like it's probably related to the fix in 7c5045fc18\n(ref-filter: apply fallback refname sort only after all user sorts,\n2020-05-03).  That was part of the 2.27.0 release.  Let's see if that\nexplains what you're seeing.\n\n> I need to sort tags first by the date of the pointed commit, then by\n> the date of the tag creation when available (I understand that\n> lightweight tags don't store their creation date, so multiple\n> lightweight tags on a single commit may not sort consistently). Let me\n> give a concrete example.\n>\n> Given a repository with this setup, using annotated tags:\n>\n> git init\n> echo hi > foo.txt\n> git add .\n> git commit -m \"first\"\n> git tag v0.1.0 -m \"A\"\n> echo bye > foo.txt\n> git add .\n> git commit -m \"second\"\n> git tag v0.2.0 -m \"B\"\n> git tag v0.1.1 HEAD~1 -m \"C\"\n>\n> I get the desired sort results in 2.21.0:\n>\n> $ git tag --merged HEAD --sort -taggerdate --sort -committerdate\n> v0.2.0\n> v0.1.1\n> v0.1.0\n\nAs far as I understand, committerdate should have no effect on annotated\ntags (i.e. it's always a tie).  So I'd guess that you're just happening\nto see the sorting you expect due the inappropriate refname fallback\ndescribed in 7c5045fc18:\n\n  This worked correctly for a single \"--sort\" option, but not for multiple\n  ones. We'd break any ties in the first key with the refname and never\n  evaluate the second key at all.\n\n> However, in 2.27.0, the first listed tag is the tag that was most\n> recently created, rather than the one pointing to the newest commit:\n>\n>\n> $ git tag --merged HEAD --sort -taggerdate --sort -committerdate\n> v0.1.1\n> v0.2.0\n> v0.1.0\n\nBased on the description above, I think the second key (-taggerdate) is\nnow coming into play.\n\n> If this is intentional, how can I achieve the desired sort order in\n> newer versions of Git?\n\nTry using * to refer to the commit that the tag points to:\n\n    $ git tag --sort -taggerdate --sort '-*committerdate'\n"},{"id":"406507","messageId":"CAKqNo6QCa2bGF3Uj-0ewh-_O+_qTOeOFYOM2k_daXw-vGg+xVg@mail.gmail.com","threadId":"54314","inReplyTo":"877dsffaq0.fsf@kyleam.com","subject":"Re: Differences in compound tag sorting between 2.27.0 and 2.21.0","fromName":"Matthew Timothy Kennerly","fromEmail":"mtkennerly@gmail.com","sentAt":"2020-09-27T18:26:05Z","receivedAt":"2020-09-27T18:26:19Z","isPatch":false,"sender":{"key":"mtkennerly@gmail.com","avatar":null},"body":"Good call - I see the old behavior with 2.26.0.\n\n> $ git tag --sort -taggerdate --sort '-*committerdate'\n\nThat gives me the desired result with the annotated tag example I\ngave, but if I do the same repository setup steps with lightweight\ntags, then it inverts the order:\n\n    # Lightweight tag repo\n    $ git tag --merged HEAD --sort -taggerdate --sort '-*committerdate'\n    v0.1.0\n    v0.1.1\n    v0.2.0\n\nIt looks like I can support both setups at once by using\n-committerdate plus -*committerdate, though:\n\n    # Annotated tag repo\n    $ git tag --merged HEAD --sort -taggerdate --sort -committerdate\n--sort '-*committerdate'\n    v0.2.0\n    v0.1.1\n    v0.1.0\n\n    # Lightweight tag repo\n    $ git tag --merged HEAD --sort -taggerdate --sort -committerdate\n--sort '-*committerdate'\n    v0.2.0\n    v0.1.0\n    v0.1.1\n\nIt's fine for me that the order isn't exactly the same, as long as\nv0.2.0 is listed first.\n\nThanks for the help!\n\nMTK\n\nOn Sun, Sep 27, 2020 at 12:25 PM Kyle Meyer <kyle@kyleam.com> wrote:\n>\n> Matthew Timothy Kennerly writes:\n>\n> > Hello,\n> >\n> > I've run into a difference in the results for a compound tag sort\n> > between 2.21.0 and 2.27.0 (I believe also applies to 2.28.0), and I'm\n> > not sure if it's an intentional difference or if there's still some\n> > way to achieve the old behavior with newer Git versions. For\n> > reference, I'm using Windows.\n>\n> This sounds like it's probably related to the fix in 7c5045fc18\n> (ref-filter: apply fallback refname sort only after all user sorts,\n> 2020-05-03).  That was part of the 2.27.0 release.  Let's see if that\n> explains what you're seeing.\n>\n> > I need to sort tags first by the date of the pointed commit, then by\n> > the date of the tag creation when available (I understand that\n> > lightweight tags don't store their creation date, so multiple\n> > lightweight tags on a single commit may not sort consistently). Let me\n> > give a concrete example.\n> >\n> > Given a repository with this setup, using annotated tags:\n> >\n> > git init\n> > echo hi > foo.txt\n> > git add .\n> > git commit -m \"first\"\n> > git tag v0.1.0 -m \"A\"\n> > echo bye > foo.txt\n> > git add .\n> > git commit -m \"second\"\n> > git tag v0.2.0 -m \"B\"\n> > git tag v0.1.1 HEAD~1 -m \"C\"\n> >\n> > I get the desired sort results in 2.21.0:\n> >\n> > $ git tag --merged HEAD --sort -taggerdate --sort -committerdate\n> > v0.2.0\n> > v0.1.1\n> > v0.1.0\n>\n> As far as I understand, committerdate should have no effect on annotated\n> tags (i.e. it's always a tie).  So I'd guess that you're just happening\n> to see the sorting you expect due the inappropriate refname fallback\n> described in 7c5045fc18:\n>\n>   This worked correctly for a single \"--sort\" option, but not for multiple\n>   ones. We'd break any ties in the first key with the refname and never\n>   evaluate the second key at all.\n>\n> > However, in 2.27.0, the first listed tag is the tag that was most\n> > recently created, rather than the one pointing to the newest commit:\n> >\n> >\n> > $ git tag --merged HEAD --sort -taggerdate --sort -committerdate\n> > v0.1.1\n> > v0.2.0\n> > v0.1.0\n>\n> Based on the description above, I think the second key (-taggerdate) is\n> now coming into play.\n>\n> > If this is intentional, how can I achieve the desired sort order in\n> > newer versions of Git?\n>\n> Try using * to refer to the commit that the tag points to:\n>\n>     $ git tag --sort -taggerdate --sort '-*committerdate'\n"},{"id":"406511","messageId":"871rinf0z5.fsf@kyleam.com","threadId":"54314","inReplyTo":"CAKqNo6QCa2bGF3Uj-0ewh-_O+_qTOeOFYOM2k_daXw-vGg+xVg@mail.gmail.com","subject":"Re: Differences in compound tag sorting between 2.27.0 and 2.21.0","fromName":"Kyle Meyer","fromEmail":"kyle@kyleam.com","sentAt":"2020-09-27T19:55:58Z","receivedAt":"2020-09-27T20:04:15Z","isPatch":false,"sender":{"key":"kyle@kyleam.com","avatar":"https://avatars.githubusercontent.com/u/1297788?v=4"},"body":"Matthew Timothy Kennerly writes:\n\n>> $ git tag --sort -taggerdate --sort '-*committerdate'\n>\n> That gives me the desired result with the annotated tag example I\n> gave, but if I do the same repository setup steps with lightweight\n> tags, then it inverts the order:\n>\n>     # Lightweight tag repo\n>     $ git tag --merged HEAD --sort -taggerdate --sort '-*committerdate'\n>     v0.1.0\n>     v0.1.1\n>     v0.2.0\n\nYes, that depends on annotated tags.  For lightweight tags, there's no\ntag object to dereference to a commit.\n\n> It looks like I can support both setups at once by using\n> -committerdate plus -*committerdate, though:\n>\n>     # Annotated tag repo\n>     $ git tag --merged HEAD --sort -taggerdate --sort -committerdate\n> --sort '-*committerdate'\n>     v0.2.0\n>     v0.1.1\n>     v0.1.0\n>\n>     # Lightweight tag repo\n>     $ git tag --merged HEAD --sort -taggerdate --sort -committerdate\n> --sort '-*committerdate'\n>     v0.2.0\n>     v0.1.0\n>     v0.1.1\n>\n> It's fine for me that the order isn't exactly the same, as long as\n> v0.2.0 is listed first.\n\nFor the lightweight case, v0.1.1 and v0.1.0 point to the same commit and\ntaggerdate has no effect because there are no tag objects, so it falls\nback to sorting v0.1.0 and v0.1.1 by refname.\n\nGiven your stated goal of \"[sorting] tags first by the date of the\npointed commit, then by the date of the tag creation when available\", I\ndon't see a better solution than what you landed on.  creatordate is\nnice for handling a mix of annotated and lightweight tags, but it\ndoesn't help in your case because you want to give precedence to the\ncommitterdate of the commit that a tags points to.  (Also, I'm not sure\nwhat the wider context for this sorting is, but perhaps just\n--sort=-version:refname would do what you want?)\n\n"},{"id":"406513","messageId":"CAKqNo6T2RMCgEhTcweicN9w0+tCDKcnsJ93vLKTQem4Sc6-qcw@mail.gmail.com","threadId":"54314","inReplyTo":"871rinf0z5.fsf@kyleam.com","subject":"Re: Differences in compound tag sorting between 2.27.0 and 2.21.0","fromName":"Matthew Timothy Kennerly","fromEmail":"mtkennerly@gmail.com","sentAt":"2020-09-27T20:35:17Z","receivedAt":"2020-09-27T20:35:31Z","isPatch":false,"sender":{"key":"mtkennerly@gmail.com","avatar":null},"body":"On Sun, Sep 27, 2020 at 3:56 PM Kyle Meyer <kyle@kyleam.com> wrote:\n> (Also, I'm not sure\n> what the wider context for this sorting is, but perhaps just\n> --sort=-version:refname would do what you want?)\n\nUnfortunately, I can't make any assumptions about how the versions\nlook. This is for Dunamai ( https://github.com/mtkennerly/dunamai ),\nwhich computes a dynamic version based on the distance from the most\nrecent version-like tag. Although it encourages a reasonable default,\nthe meaning of \"version-like\" can be configured to handle arbitrary\nversioning schemes.\n\nMTK\n"}]}