Am 18.02.2017 um 12:15 schrieb Alex Hoffman:
No one commented the fact, that I find this very confusing. Don't you
find this confusing? I will underline, that 'git bisect good v.good'
will fail if the commit 'v.good' is not a parent of the bad commit,
meaning there MUST be at least a path between 'v.good' and 'v.bad',
thus I would expect it looks on this path ONLY. Beside that, this is
what I understand by 'binary search' (to search on this commit path).
But this is not how Git works. Git computes graph differences, i.e., it
subtracts from the commits reachable from v.bad those that are reachable
from v.good. This leaves more than just those on some path from v.good
to v.bad. And it should work this way. Consider this history:
--o--o--o--G--X
\ \
x--x--x--x--X--B--
When you find B bad and G good, than any one of the x or X may have
introduced the breakage, not just one of the X.
Correct. The assumption of bisection is that there is only one
transition between GOOD and BAD. By violating that assumption,
anything can happen.
I did not find that in the manpage or did I miss it? Why would someone
assume that the commit graph looks in a certain way?
There is no restriction in the commit graph. The only restriction,
actually assumption, is that there is *one* transition from good to bad
and no transition from bad to good. Otherwise, bisection cannot work.
I assume, that
'git bisect' was not thought through and that it considers the first
directed path between v.good and v.bad, instead of all paths (in my
example graph there are two such paths). I will also underline that
git bisect was designed to work with multiple good commits and one bad
commit (also multiple paths), but probably NOT with multiple paths
between the same pair of good and bad commits.
Oh, IMO git bisect was well thought through. If it considered just paths
from good to bad, it would not given the correct answer. See the example
history above. Bisect authors would not have deemed that sufficiently
good ;)
-- Hannes