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

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

[Halil Öztürk]

Hello team,

Passing a number as an option to "git tags" command should display latest tags.

e.g. "git tags -5" will display last 5 tags only.

Similar behavior to "git log -5"

Thanks,
Halil

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

[Jacob Keller]

On Wed, Jul 22, 2015 at 10:17 AM, Halil Öztürk <halilozturk55@gmail.com> wrote:
> Hello team,
>
> Passing a number as an option to "git tags" command should display latest tags.
>
> e.g. "git tags -5" will display last 5 tags only.
>
> Similar behavior to "git log -5"
>
> Thanks,
> Halil
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


While interesting, this would only really work for annotated tags. How
would you define order? tags are normally shown in sorted lexical
order (or version-order if you pass the --sort parameter).
Non-annotated tags do not contain the date time, and using the
commit's date information may not be accurate. While it is possible to
say show "the 5 most recent tags on a particular branch of history"
that would be using the log to determine this.

What exactly would you expect the behavior to be with tags? That might
help figure out what could be done instead.

Regards,
Jake

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

[Andreas Schwab]

Halil Öztürk <halilozturk55@gmail.com> writes:

> Passing a number as an option to "git tags" command should display latest tags.

How do you define "the latest tags"?  By tag creation?  Lightweight
tags don't have any kind of creation time attached.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Junio C Hamano]

Halil Öztürk <halilozturk55@gmail.com> writes:

> Passing a number as an option to "git tags" command should display latest tags.
>
> e.g. "git tags -5" will display last 5 tags only.

I think this conflates two unrelated things.

 - Ordering tags not by refnames (i.e. default) but by "time".

 - Limiting the output by count.

The latter is what "| head -n 5" and/or "| tail -n 5" are for, so it
would be at most "nice to have"; I am indifferent in the sense that
I won't work on it, but I'd take a look if somebody sent a patch
that was cleanly done.

The former, sort by "time", is interesting, but you need to define
what to do with various corner cases.  For example, some people may
be 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.

   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.

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.

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> 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.

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

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 22.07.2015 21:20:
> Junio C Hamano <gitster@pobox.com> 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.
> 

While not quite being intended for that purpose,

git log --oneline --decorate --simplify-by-decoration [-n] --tags

(or with a custom format instead of "--oneline --decorate") may come
close to what you want.[*]

Michael

[*] As Linus once described it (iirc): oooh, evil. I like it.

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

[Jacob Keller]

On Thu, Jul 23, 2015 at 2:39 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
>
> While not quite being intended for that purpose,
>
> git log --oneline --decorate --simplify-by-decoration [-n] --tags
>
> (or with a custom format instead of "--oneline --decorate") may come
> close to what you want.[*]
>
> Michael
>
> [*] As Linus once described it (iirc): oooh, evil. I like it.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Yep, that's pretty much how a build system I've had to use does it.
Sadly, this is quite slow, and I'm not sure if doing it built into the
tag via for-each-ref would be faster? I mean obviously having to look
at each commit is slower than just the tag name, but it might be
faster than parsing through the log process? Though the log output has
the advantage that it only shows you tags "on" a given branch.

Regards,
Jake

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

[Junio C Hamano]

Jacob Keller <jacob.keller@gmail.com> writes:

> Yep, that's pretty much how a build system I've had to use does it.
> Sadly, this is quite slow, and I'm not sure if doing it built into the
> tag via for-each-ref would be faster?

Is the description in "git for-each-ref --help" somehow unreadable?

       An example directly producing formatted text. Show the most
       recent 3 tagged commits:

           #!/bin/sh

           git for-each-ref --count=3 --sort='-*authordate' \
           --format='From: %(*authorname) %(*authoremail)
           Subject: %(*subject)
           Date: %(*authordate)
           Ref: %(*refname)

           %(*body)
           ' 'refs/tags'

If you only need the name of the ref, you can use a lot simpler
format string, e.g.

    git for-each-ref --count=3 --sort='-*authordate' \
      --format='%(refname:short)' refs/tags

    git for-each-ref --count=3 --sort='-taggerdate' \
      --format='%(refname:short)' refs/tags

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

[Jacob Keller]

On Thu, Jul 23, 2015 at 11:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jacob Keller <jacob.keller@gmail.com> writes:
>
>> Yep, that's pretty much how a build system I've had to use does it.
>> Sadly, this is quite slow, and I'm not sure if doing it built into the
>> tag via for-each-ref would be faster?
>
> Is the description in "git for-each-ref --help" somehow unreadable?
>
>        An example directly producing formatted text. Show the most
>        recent 3 tagged commits:
>
>            #!/bin/sh
>
>            git for-each-ref --count=3 --sort='-*authordate' \
>            --format='From: %(*authorname) %(*authoremail)
>            Subject: %(*subject)
>            Date: %(*authordate)
>            Ref: %(*refname)
>
>            %(*body)
>            ' 'refs/tags'
>
> If you only need the name of the ref, you can use a lot simpler
> format string, e.g.
>
>     git for-each-ref --count=3 --sort='-*authordate' \
>       --format='%(refname:short)' refs/tags
>
>     git for-each-ref --count=3 --sort='-taggerdate' \
>       --format='%(refname:short)' refs/tags
>

That's significantly better than what this system does, but sadly the
team that owns it doesn't exactly understand git. Pretty sure they
tend to just use whatever scriptlet they got working, which happens to
be based on log...  I've tried to help them, but generally hasn't been
a successful relationship there.

Regards,
Jake

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

[Junio C Hamano]

Jacob Keller <jacob.keller@gmail.com> writes:

> On Thu, Jul 23, 2015 at 11:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jacob Keller <jacob.keller@gmail.com> writes:
>>
>>> Yep, that's pretty much how a build system I've had to use does it.
>>> Sadly, this is quite slow, and I'm not sure if doing it built into the
>>> tag via for-each-ref would be faster?
>>
>> Is the description in "git for-each-ref --help" somehow unreadable?
>> ...
>> If you only need the name of the ref, you can use a lot simpler
>> format string, e.g.
>>
>>     git for-each-ref --count=3 --sort='-*authordate' \
>>       --format='%(refname:short)' refs/tags
>>
>>     git for-each-ref --count=3 --sort='-taggerdate' \
>>       --format='%(refname:short)' refs/tags
>>
>
> That's significantly better than what this system does, but sadly the
> team that owns it doesn't exactly understand git. Pretty sure they
> tend to just use whatever scriptlet they got working, which happens to
> be based on log...  I've tried to help them, but generally hasn't been
> a successful relationship there.

If your build people refuse to switch from an unreliable way of
parsing "log" output that is not meant for machine consumption, then
it wouldn't make any difference what the answer to your "I'm not
sure if doing it built into ... be faster?" X-<.

By the way, I was referring to that question, pointing out that you
do not have be wondering.  It is already there, and as I said a few
messages ago already in this thread, the cross-pollination among
"for-each-ref", "branch -l" and "tag -l" is happening as part of
this year's GSoC program.