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
threads / discuss / 39917
Feature Request: Passing a number as an option to git tags for displaying latest tags
Subject: Feature Request: Passing a number as an option to git tags for displaying latest tags
Jacob KellerRe: Feature Request: Passing a number as an option to git tags for displaying latest tags
On Wed, Jul 22, 2015 at 10:17 AM, Halil Öztürk <halilozturk55@gmail.com> wrote:
Show 14 quoted lines
> 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
Andreas SchwabRe: Feature Request: Passing a number as an option to git tags for displaying latest tags
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."
Junio C HamanoRe: Feature Request: Passing a number as an option to git tags for displaying latest tags
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.
Junio C HamanoRe: Feature Request: Passing a number as an option to git tags for displaying latest tags
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.
Michael J GruberRe: Feature Request: Passing a number as an option to git tags for displaying latest tags
Junio C Hamano venit, vidit, dixit 22.07.2015 21:20:
Show 35 quoted lines
> 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.
Jacob KellerRe: Feature Request: Passing a number as an option to git tags for displaying latest tags
On Thu, Jul 23, 2015 at 2:39 AM, Michael J Gruber <git@drmicha.warpmail.net> wrote:
Show 15 quoted lines
> > 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
Junio C HamanoRe: Feature Request: Passing a number as an option to git tags for displaying latest tags
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/tagsJacob KellerRe: Feature Request: Passing a number as an option to git tags for displaying latest tags
On Thu, Jul 23, 2015 at 11:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 31 quoted lines
> 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
Junio C HamanoRe: Feature Request: Passing a number as an option to git tags for displaying latest tags
Jacob Keller <jacob.keller@gmail.com> writes:
Show 24 quoted lines
> 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.