Differences in compound tag sorting between 2.27.0 and 2.21.0

Differences in compound tag sorting between 2.27.0 and 2.21.0

[Matthew Timothy Kennerly]

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.

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


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


Swapping the sort options in 2.27.0 does not affect the result,
whereas swapping them in 2.21.0 produces the same result as 2.27.0.
That makes it seem like 2.27.0 is ignoring the precedence order of the
sort options.

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

Thanks,

MTK

Re: Differences in compound tag sorting between 2.27.0 and 2.21.0

[Kyle Meyer]

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'

Re: Differences in compound tag sorting between 2.27.0 and 2.21.0

[Matthew Timothy Kennerly]

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'

Re: Differences in compound tag sorting between 2.27.0 and 2.21.0

[Kyle Meyer]

Matthew Timothy Kennerly writes:

>> $ 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

Yes, that depends on annotated tags.  For lightweight tags, there's no
tag object to dereference to a commit.

> 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.

For the lightweight case, v0.1.1 and v0.1.0 point to the same commit and
taggerdate has no effect because there are no tag objects, so it falls
back to sorting v0.1.0 and v0.1.1 by refname.

Given your stated goal of "[sorting] tags first by the date of the
pointed commit, then by the date of the tag creation when available", I
don't see a better solution than what you landed on.  creatordate is
nice for handling a mix of annotated and lightweight tags, but it
doesn't help in your case because you want to give precedence to the
committerdate of the commit that a tags points to.  (Also, I'm not sure
what the wider context for this sorting is, but perhaps just
--sort=-version:refname would do what you want?)

Re: Differences in compound tag sorting between 2.27.0 and 2.21.0

[Matthew Timothy Kennerly]

On Sun, Sep 27, 2020 at 3:56 PM Kyle Meyer <kyle@kyleam.com> wrote:
> (Also, I'm not sure
> what the wider context for this sorting is, but perhaps just
> --sort=-version:refname would do what you want?)

Unfortunately, I can't make any assumptions about how the versions
look. This is for Dunamai ( https://github.com/mtkennerly/dunamai ),
which computes a dynamic version based on the distance from the most
recent version-like tag. Although it encourages a reasonable default,
the meaning of "version-like" can be configured to handle arbitrary
versioning schemes.

MTK