Am 18.02.2017 um 19:36 schrieb Alex Hoffman:
Let's consider your example with distinct names for nodes:
--o1--o2--o3--G--X1
\ \
x1--x2--x3--x4--X2--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.
But that is not the definition of transition that lets you pin-point the
breaking commit precisly. Assume x3 is the commit introducing the
breakage in the graph above. Even though you only know initially that G
is good and B is bad, would you not prefer to find x3 instead of X2? As
Christian said, a transition is when a commit is bad and all its parents
are good, and this definition lets you find x3.
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?
By declaring G as good, it is implied that o1 is also good. If it is in
fact bad, the assumptions of git bisect are violated (because there
would be a transition from bad to good at o2, o3, or G), and anything
can happen.
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.
And I do not see a reason why git bisect should not look at those
commits. If x3 is the commit that broke my program, I do prefer to be
pointed at x3 rather than X2.
-- Hannes