Re: Differences in compound tag sorting between 2.27.0 and 2.21.0

From: Kyle Meyer <kyle@kyleam.com>
Date: Sep 27, 2020, 16:25 UTC
Message-ID: <877dsffaq0.fsf@kyleam.com>
In-Reply-To: <CAKqNo6RJqp94uLMf8Biuo=ZvMZB9Mq6RRMrUgsLW4u1ks+mnOA@mail.gmail.com>

Matthew Timothy Kennerly writes:

Show 7 quoted lines

> Hello,
>
> I've run into a difference in the results for a compound tag sort
> between 2.21.0 and 2.27.0 (I believe also applies to 2.28.0), and I'm
> not sure if it's an intentional difference or if there's still some
> way to achieve the old behavior with newer Git versions. For
> reference, I'm using Windows.

This sounds like it's probably related to the fix in 7c5045fc18 (ref-filter: apply fallback refname sort only after all user sorts, 2020-05-03). That was part of the 2.27.0 release. Let's see if that explains what you're seeing.

Show 25 quoted lines

> I need to sort tags first by the date of the pointed commit, then by
> the date of the tag creation when available (I understand that
> lightweight tags don't store their creation date, so multiple
> lightweight tags on a single commit may not sort consistently). Let me
> give a concrete example.
>
> Given a repository with this setup, using annotated tags:
>
> git init
> echo hi > foo.txt
> git add .
> git commit -m "first"
> git tag v0.1.0 -m "A"
> echo bye > foo.txt
> git add .
> git commit -m "second"
> git tag v0.2.0 -m "B"
> git tag v0.1.1 HEAD~1 -m "C"
>
> I get the desired sort results in 2.21.0:
>
> $ git tag --merged HEAD --sort -taggerdate --sort -committerdate
> v0.2.0
> v0.1.1
> v0.1.0

As far as I understand, committerdate should have no effect on annotated tags (i.e. it's always a tie). So I'd guess that you're just happening to see the sorting you expect due the inappropriate refname fallback described in 7c5045fc18:

  This worked correctly for a single "--sort" option, but not for multiple
  ones. We'd break any ties in the first key with the refname and never
  evaluate the second key at all.

Show 8 quoted lines

> However, in 2.27.0, the first listed tag is the tag that was most
> recently created, rather than the one pointing to the newest commit:
>
>
> $ git tag --merged HEAD --sort -taggerdate --sort -committerdate
> v0.1.1
> v0.2.0
> v0.1.0

Based on the description above, I think the second key (-taggerdate) is now coming into play.

> If this is intentional, how can I achieve the desired sort order in
> newer versions of Git?

Try using * to refer to the commit that the tag points to:

    $ git tag --sort -taggerdate --sort '-*committerdate'