git describe and "the smallest number of commits possible"

["Kévin Le Gouguec" <kevin.legouguec@gmail.com>]

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.