Junio C Hamano <gitster@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html