Hi,
Not sure this is a bug; I might just misunderstand git-describe's
algorithm. I am on Debian Jessie with git version 2.1.4; I also get
the same behavior on next (98096fd7a85b93626db8757f944f2d8ffdf7e96a).
I am trying to get the most recent tag on Emacs's repository[1]. With
master checked out (at eaa5dc9d102d10c79f10bee1994ad922b8fcf9c4),
running
$ git describe --tags --debug --match 'emacs-*'
Yields:
searching to describe HEAD
lightweight 129568 emacs-25.1
lightweight 3807 emacs-25.1-rc2
lightweight 3847 emacs-25.1-rc1
annotated 3906 emacs-25.2
annotated 3941 emacs-25.2-rc2
lightweight 3947 emacs-25.0.95
annotated 3957 emacs-25.2-rc1
annotated 4001 emacs-25.1.91
lightweight 4026 emacs-25.0.94
lightweight 4050 emacs-25.1.90
traversed 129978 commits
more than 10 tags found; listed 10 most recent
gave up search at 5c587fdff164e8b90beb47f6da64b4884290e40a
emacs-25.1-129568-geaa5dc9
I am somewhat surprised that git does not choose "emacs-25.2". The
manpage says:
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.
If I run "git log tag..input":
$ git log --oneline emacs-25.1.. | wc -l
4847
$ git log --oneline emacs-25.2.. | wc -l
4514
I added a bunch of debugging prints to compare_pt() in
builtin/describe.c:
+ fprintf(stderr, "comparing %s against %s\n",
+ a->name->path, b->name->path);
+
if (a->depth != b->depth) {
+ fprintf(stderr, "\tdepths: %d-%d = %d\n",
+ a->depth, b->depth, a->depth-b->depth);
return a->depth - b->depth;
}
Sample:
comparing emacs-25.2 against emacs-25.1
depths: 3906-3790 = 116
I see that after sorting, describe() calls finish_depth_computation(),
which updates the depth of each candidate. As far as I can see, this
update is only reflected in --debug's output, and does not change
which candidate is deemed "best". Is this on purpose?
In advance, thank you for your patience. I apologize for
- not having run blame or log on builtin/describe.c yet; that could
show me something that would help me understand what is going on;
- not being able to reduce the test case (I tried to create a smaller
repository with a somewhat similar topology, to no avail);
- maybe having missed something from the branch topology that explains
this result;
- maybe having gone cross-eyed on the code and misinterpreted it.
[1]: https://git.savannah.gnu.org/git/emacs.git
To provide an overview of the topology, I tried running
$ git log --graph --oneline --decorate --simplify-by-decoration
But there is some noise coming from merged feature branches. To
simplify the picture, if we only consider master and the emacs-25
maintenance branch, the graph looks like this:
* (master)
*\
*\* (tag: emacs-25.2, emacs-25)
|\* (tag: emacs-25.2-rc2)
| * (tag: emacs-25.2-rc1)
* |
*\|
*\* (tag: emacs-25.1)
|\* (tag: emacs-25.1-rc2)
| * (tag: emacs-25.1-rc1)
|/
*
I guess it is possible that some feature branches make the topology
complex enough that weird things may happen during traversal; for
example, the "concurrency" branch started off master before emacs-25,
and was merged between 25.1 and 25.2.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
