Differences in compound tag sorting between 2.27.0 and 2.21.0

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

Matthew Timothy Kennerly writes:

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.

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.

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

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

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

Good call - I see the old behavior with 2.26.0.

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:

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

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?)

On Sun, Sep 27, 2020 at 3:56 PM Kyle Meyer <kyle@kyleam.com> wrote:

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