You're correct - "git bisect" will not always be able to find an exact
half-way point, and I was wrong to imply that it will always be quite that
close.
It's easily off by a few commits because of merges that make it harder to
find a good bisection point, but it should never (practically) be off by
quite as much as you saw.
For example, I could expect that from 127 commits, it would go down to 70
rather than 64. But not to 110 - not unless there are some *really*
strange patterns with lots of criss-crossing merges.
And indeed, for me, using the same commit ID's as you used, I see a nice
bisection to just about exactly half.
You really do want to use git-1.5.x these days.
It does look like 1.4.4.4 may have a bug, although I'm really surprised:
we've certainly tweaked stuff in bisection, but I and others have used
"git bisect" since long before the git-1.4 days, and it has always worked
ok. So I wonder if it's something specific to that debian build.
Or possibly to the fact that you have some other dirty state (you might
want to do a "git diff HEAD" to see what the changes are, and maybe a "git
checkout -f" to get rid of any differences)
I'm surprised that debuan
Ok, something deleted an empty file. Probably "make distclean". Our "make
clean" is sometimes too aggressive, and we generally shouldn't have empty
files.
but this one has actually been modified. To this:
And finally,
That one also has been actually deleted. And "make distclean" doesn't do
that. You have something else going on.
Linus
-
