From: "Alex Hoffman" <spec@xxxxxx>
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.
Thank you for clarifying how git bisect works. How did you find that
out? Did you check the source code? If that is not documented in the
man page may be it worth documenting it in order to avoid future
confusion for other users.
Any suggestions for improving the documentation are always worthwhile. As
someone who asked, what extra info would have helped?
Even beetter if it looks like a patch ;-)
Let's consider your example with distinct names for nodes:
--o1--o2--o3--G--X1
\ \
x1--x2--x3--x4--X1--B--
It makes sense that git bisect is expecting a single transition, as
this is a precondition for a binary search to work. My definition of
"the transition" is a commit with at least one of its parents as a
good version, but the commit itself a bad version. I hope we agree
that git bisect's mission is to search for this transition (as I
suppose that most of people need such a functionality from git, if not
exactly from git bisect). How could be x1 or x3 be the transition, if
chances are that o1 is not a good version? Of course it would make
sense to me if bisect would check o1 whether good and only then to
check also x1-x3, but this is not what git makes (at least not in my
initial example).
If you consider that git bisect's mission is different from finding
the transition, could you please explain what exact commit git bisect
is supposed to return (ideally with terms from the graph theory) and
when it makes sense to return that? Because I do not see any sense in
looking in the path x1-x3 without knowing that those commits may be a
transition.
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
You definitely convinced me that git MUST search more than only in the
paths between good and bad commits, as the good commit G does not have
to be the first good commit (thank you for that). My problem/confusion
is that it returns something that does not make sense to me, because
it does not make sure it returns a transition.
VG
PS: thank you for continuing this discussion.
--
Philip