Thanks folks, that makes for some interesting feedback. On the best way to accomplish the task at hand: thank you for the examples, Sylvie! While skimming git-tag(1)'s manpage, I also found this gem:
--sort=<type> Sort in a specific order. Supported type is "refname" (lexicographic order), "version:refname" or "v:refname" (tag names are treated as versions). Prepend "-" to reverse sort order. When this option is not given, the sort order defaults to the value configured for the tag.sort variable if it exists, or lexicographic order otherwise. See git-config(1). This is for version 2.1.4. With this version, "version:refname" still sorts lexicographically when confronted with the same prefix, so e.g. "42" ranks lower than "42-rc1". As of 2.12, the versionsort.suffix configuration variable lets us tell Git that "42" ranks higher than "42-rc1": $ git -c versionsort.suffix=-rc tag --list --sort=-version:refname 'emacs-[0-9]*' emacs-25.2 emacs-25.2-rc2 emacs-25.2-rc1 emacs-25.1.91 emacs-25.1.90 emacs-25.1 emacs-25.1-rc2 emacs-25.1-rc1 … This excludes "emacs-pretest-*" versions though. Also, it sorts *every* commit in the repository, so this does not solve the more general problem of finding the most recent tag *describing HEAD*, when HEAD wanders away from master. On understanding git-describe's behavior: thanks for the pointer Philip, I will have a look at this thread. A quick search for "describe tag" also turned up this one: https://public-inbox.org/git/xmqqy3sf7mxo....@gitster.mtv.corp.google.com/ I have not read it thoroughly yet, but it might also help shed some light on what is happening here. As for whether the docs I quoted match my version of Git, well, I quoted my distribution's manpage. This paragraph shows up both in 2.1.4 and 2.14. And both versions have the same behavior: they both return "emacs-25.1", while the paragraph suggests that it should return whichever tag gives the fewest commits when running "git log tag..input". To recap: > If multiple tags were found during the walk then the tag which has > the fewest commits different from the input commit-ish will be > selected and output. Here fewest commits different is defined as the > number of commits which would be shown by `git log tag..input` will > be the smallest number of commits possible. $ git log --oneline emacs-25.1.. | wc -l 4847 $ git log --oneline emacs-25.2.. | wc -l 4514 $ git describe --tags emacs-25.1-129568-geaa5dc9 On Git's discoverability: Michael, to complement Sylvie and Buga's answers, there are a couple of things that come to mind: - I do not think learning "all the things that Git can do" is a worthy investment; it is versatile enough that it can serve everyone and their grandmother's purposes. It is always nice to discover ways to improve your daily usage, but in the grand scheme of things one is probably better off sticking to what his collaborators' workflow entails, picking up more advanced knowledge as they go when/if they feel like it. - Good UIs can trim the flexibility from mind-boggling down to actually helpful. As an Emacs user, Magit is a fine example of interface that - narrows my choices down to what is relevant at a given time; - holds my hand while trying out more advanced actions; - lets me see what is going on under the hood so that I can - connect the dots and learn more things if I feel like it; - pack some debugging information in my bag before leaving for a help-seeking journey on the Internet. And then my mathematical, "you asked for it" reply: $ man -S 1 -k ^git- : Also available as versionsort.prereleaseSuffix from 2.4, though this one was deprecated. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.