Re: Git bisect does not find commit introducing the bug

From: Johannes Sixt <j6t@kdbg.org>
Date: Feb 18, 2017, 22:37 UTC
Message-ID: <148a585a-33df-1adb-6410-5c4fe09202b0@kdbg.org>
In-Reply-To: <CAMX8fZW2y+iPRfSbXVcHufbM+CsqgekS_0WnCEJ++=njy_TvKg@mail.gmail.com>

Am 18.02.2017 um 19:36 schrieb Alex Hoffman:

Show 10 quoted lines

> 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.

Show 5 quoted lines

> 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.

Show 6 quoted lines

> 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