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[1] 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-
[1]: 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.
