Re: Differences in compound tag sorting between 2.27.0 and 2.21.0

[Kyle Meyer <kyle@kyleam.com>]

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