On 5 Jan, 14:40, Thomas Ferris Nicolaisen <tfn...@gmail.com> wrote:
> I still believe that there's something fishy going on in your test.. Care
> to share some concrete examples?

Immediately after git bisect run HEAD is at d9:

git rev-parse HEAD

The bad commit is:
sed -n s'/\([0-9a-f]\{40\}\) is the first bad commit/\1/p' git-bisect-

The log:

git bisect log | grep 'git bisect'
git bisect start
git bisect bad e8035d1d31d528ade3d991c575be7140fe17624c
git bisect good a0dea7d93fc40686c5e0b07cf04c2fda6a53dc9e
git bisect good c5612aa2a37b3e610e726fdc2fcc9d5c8c9adf17
git bisect good 7f47189e0ba6fa1ad19c32b8059b4f39d8e6ff75
git bisect good 0c78b8538c5966cf9424c9bb2128324779ce00ca
git bisect good d9ab70394d306d5ab450513b2f69c8b81f6f255c

e8 is the only bad commit in this case, but I think it boils down to
if the last run which was performed was a good or a bad. In my case it
was a good, in your case if was a bad.

Seems like git bisect run just stops with HEAD at the last iteration,
but it would have been nice if it was a way to get the bad commit
after a successful bisect

git --version
git version

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to