Fletcher Charest <fletcher.charest@gmail.com> writes:

> Nick, you say you could not reproduce the bug using version
> 8.2.5h-667-g971dc4, but you did with version 8.2.5h-888-g798bb8d. Just
> out of curiosity: does the '888' in '8.2.5h-888-g798bb8d' is a number
> that is incremented chronologically? If this is correct (I'm not
> familiar with this at all), FWIW, the bug was not caused only by the
> patch '8.2.5h-888-g798bb8d', since I observed it also with version
> 8.2.5h-94-g91175a.
>

888 is the number of commits since the commit that was tagged
'8.2.5h'. Unfortunately, that number can be misleading: in the
face of merges, there may be multiple paths that lead from some commit
back to the tagged commit (run `gitk master' if you want to see the multiple
paths), so the "number of commits since the tag" is ambiguous. It is
only unambiguous if the history is strictly linear.

If you do `git log --oneline -100' on master, you'll see that there is a
merge commit d25846b that looks like this:

,----
| $ git show d25846b
| commit d25846b2340e32dea93fc89ea432f74a7f64d950
| Merge: f261833 91175a3
| Author: Nicolas Goaziou <n.goaziou@gmail.com>
| Date:   Sat Mar 29 15:02:10 2014 +0100
|
|     Merge branch 'maint'
`----

The merge commit has two parents: f261833 and our old friend 91175a3.

Try git describe on this commit:

   git describe d25846b

It's only one commit ahead of 91175a3 but I get

   release_8.2.5h-873-gd25846b

so it's 873 commits ahead of 8.2.5h, not 95! But that's because `git
describe' takes a different, much longer, path back to the tagged
commit: it follows the first parent of the merge commit.

So I'm pretty sure that the patch that the bisection fingered is
indeed the culprit.

I believe this is correct but if not, Achim will correct me:-)

--
Nick