Code

Compute accurate distances in git-describe before output.
authorShawn O. Pearce <spearce@spearce.org>
Sat, 27 Jan 2007 06:54:21 +0000 (01:54 -0500)
committerJunio C Hamano <junkio@cox.net>
Sun, 28 Jan 2007 10:08:51 +0000 (02:08 -0800)
commit1b600e659abc7e409c9d830e332d3cef01062c1c
tree5750afef1764e5a72c34ebd48a3129d380c2e145
parent1891261ed3ed52022ae5322b4db338f9d5112909
Compute accurate distances in git-describe before output.

My prior change to git-describe attempts to print the distance
between the input commit and the best matching tag, but this distance
was usually only an estimate as we always aborted revision walking
as soon as we overflowed the configured limit on the number of
possible tags (as set by --candidates).

Displaying an estimated distance is not very useful and can just be
downright confusing.  Most users (heck, most Git developers) don't
immediately understand why this distance differs from the output
of common tools such as `git rev-list | wc -l`.  Even worse, the
estimated distance could change in the future (including decreasing
despite no rebase occuring) if we find more possible tags earlier
on during traversal.  (This could happen if more tags are merged
into the branch between queries.)  These factors basically make an
estimated distance useless.

Fortunately we are usually most of the way through an accurate
distance computation by the time we abort (due to reaching the
current --candidates limit).  This means we can simply finish
counting out the revisions still in our commit queue to present
the accurate distance at the end.  The number of commits remaining
in the commit queue is probably less than the number of commits
already traversed, so finishing out the count is not likely to take
very long.  This final distance will then always match the output of
`git rev-list | wc -l`.

We can easily reduce the total number of commits that need to be
walked at the end by stopping as soon as all of the commits in the
commit queue are flagged as being merged into the already selected
best possible tag.  If that's true then there are no remaining
unseen commits which can contribute to our best possible tag's
depth counter, so further traversal is useless.

Basic testing on my Mac OS X system shows there is no noticable
performance difference between this accurate distance counting
version of git-describe and the prior version of git-describe,
at least when run on git.git.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
builtin-describe.c