Re: Differences in compound tag sorting between 2.27.0 and 2.21.0

[Matthew Timothy Kennerly <mtkennerly@gmail.com>]

Good call - I see the old behavior with 2.26.0.

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

That gives me the desired result with the annotated tag example I
gave, but if I do the same repository setup steps with lightweight
tags, then it inverts the order:

    # Lightweight tag repo
    $ git tag --merged HEAD --sort -taggerdate --sort '-*committerdate'
    v0.1.0
    v0.1.1
    v0.2.0

It looks like I can support both setups at once by using
-committerdate plus -*committerdate, though:

    # Annotated tag repo
    $ git tag --merged HEAD --sort -taggerdate --sort -committerdate
--sort '-*committerdate'
    v0.2.0
    v0.1.1
    v0.1.0

    # Lightweight tag repo
    $ git tag --merged HEAD --sort -taggerdate --sort -committerdate
--sort '-*committerdate'
    v0.2.0
    v0.1.0
    v0.1.1

It's fine for me that the order isn't exactly the same, as long as
v0.2.0 is listed first.

Thanks for the help!

MTK

On Sun, Sep 27, 2020 at 12:25 PM Kyle Meyer <kyle@kyleam.com> wrote:
>
> Matthew Timothy Kennerly writes:
>
> > 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.
>
> > 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.
>
> > 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'