Subject: Re: Feature Request: Passing a number as an option to git tags for displaying latest tags

From: Junio C Hamano <[email-masked]>
Date: Wed, 22 Jul 2015 12:20:46 -0700

Junio C Hamano <[email-masked]> writes:

> The former, sort by "time", is interesting, but you need to define
> what to do with various corner cases.  For example, some people may
> have one or more of the following desires:
>
>  * My project did not use tags for a long time, and started using it
>    recently starting from v1.1.0.  The first release only said
>    "Frotz version 1.0.0" in its commit log message.  I retroactively
>    did "git tag -s -m 'Frotz 1.1.0' v1.1.0" on that commit.

Obviously, I meant "git tag -s -m 'Frotz 1.0.0' v1.0.0" here.

>    In such a case, it is likely that I would want the sorting done
>    based on the committer date on the underlying commit, not the
>    tag's tagger date.
>
>  * When a bug is found, it is customary in my project to add a
>    "break-<something>" tag to the commit that introduces the bug
>    (and "fix-<something>" tag to the commit that fixes it).
>
>    When I want to find recently discovered breakages, I want the
>    tags whose names match "break-*" sorted by tagger dates, not the
>    underlying commit's committer dates.

Another use case may be one in which older tags are interesting.  In
other words, you need to be able to sort in reverse, too.

> The necessary ordering machinery to do the above already exists in
> "for-each-ref".  There is a GSoC project that works to unify various
> features spread across "for-each-ref", "branch -l" and "tag -l" and
> make them available to all of the three.

And the above is still true even with reverse-order use case.