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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 22, 2015, 19:20 UTC
Message-ID: <xmqq7fpsroc1.fsf@gitster.dls.corp.google.com>
In-Reply-To: <xmqqbnf4rohs.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

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

Show 11 quoted lines

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