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:
> 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
4793
If 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-gdcc3ef3ee7
I 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.
