Hi,
I've asked this question on the git-users Google Groups list[1], and while the answers there were interesting, I still cannot figure whether my problem comes from an actual bug, a misleading manpage, my inability to understand the code and/or the manpage, or a combination of the three.
I noticed this problem on 2.1.4 (Debian oldstable); I can reproduce it on next (7ef03bb281b2220d0f2414365e4949beb2337042). Quoting git-describe(1)'s SEARCH STRATEGY section:
Show 5 quoted lines
> 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.
To put it shortly, after cloning GNU Emacs's repository[2]:
$ git describe --tags
emacs-25.1-129847-gdcc3ef3ee7
$ git log --oneline emacs-25.1.. | wc -l
5126
$ git log --oneline emacs-25.2.. | wc -l
4793If I am reading it correctly, the manpage suggests that emacs-25.2 should be picked in this situation ("log emacs-25.2.." shows fewer commits than "log emacs-25.1..").
Once more with --debug:
$ git describe --debug --tags
searching to describe HEAD
lightweight 129847 emacs-25.1
lightweight 4086 emacs-25.1-rc2
lightweight 4126 emacs-25.1-rc1
annotated 4185 emacs-25.2
annotated 4220 emacs-25.2-rc2
lightweight 4226 emacs-25.0.95
annotated 4236 emacs-25.2-rc1
annotated 4280 emacs-25.1.91
lightweight 4305 emacs-25.0.94
lightweight 4329 emacs-25.1.90
traversed 130257 commits
more than 10 tags found; listed 10 most recent
gave up search at 5c587fdff164e8b90beb47f6da64b4884290e40a
emacs-25.1-129847-gdcc3ef3ee7I tried to get a sense of what builtin/describe.c is doing (see [1] for some debug printfs); to summarize what I figured:
- When QSORT() is called in describe(), emacs-25.1's depth is smaller than emacs-25.2's.
- finish_depth_computation() updates the best candidate's depth; AFAIU this update's only purpose is to make the displayed suffix more accurate.
That is all I have right now. I apologize for failing to come up with a simpler test case (I tried to make toy repositories with a similar topology to reproduce the issue, to no avail). To conclude, as far as I can tell, one of the following holds:
- something about this repository[3] causes git-describe(1) to not work as advertised;
- I fail at reading manuals.
[1]: https://groups.google.com/forum/?fromgroups#!topic/git-users/tSnX-O-3aNI
[2]: https://git.savannah.gnu.org/git/emacs.git
[3]: The project's workflow sounds straightforward:
- development happens mainly on the master branch; - the emacs-25 branch receives maintenance fixes and release tags; it is periodically merged back into master; - experimental work can happen on scratch branches; these may eventually be merged back into master.
There are some complications (e.g. pull-induced merges) but if I --simplify-by-decoration I find that the repository's topology matches this description.
