From: Johannes Sixt <j6t@kdbg.org>
Date: Sat, 18 Feb 2017 09:12:14 GMT
Subject: Re: Git bisect does not find commit introducing the bug
Message-ID: <3ff5ce3c-285f-cb9a-d1d4-46323524dab7@kdbg.org>
In-Reply-To: <d4991e4b-cbc4-da14-381a-88704e457a19@gmx.net>

Am 18.02.2017 um 00:21 schrieb Stephan Beyer:
> On 02/17/2017 11:29 PM, Alex Hoffman wrote:
> *   7a9e952 (bisect bad) <BAD>
> |\
> | *   671cec2 <BAD> <--- expected
> | |\
> | * | 04c6f4b <BAD> <--- found
> * | |   3915157 <GOOD>
> |\ \ \
> | | |/
> | |/|
> | * | f4154e9 (bisect good) <GOOD>
> | * | 85855bf <BAD>
> | |/
> * | f1a36f5 <BAD>
> |/
> * 1b7fb88 <BAD>
>
> The <BAD> and <GOOD> markers are set by your definition of what good and
> what bad commits are.
>
> [...]
> In other words: bisect assumes that your repo is usually in a good state
> and you have a commit that changes it to a bad state. In your case you
> have a repo that is in a bad state and you have a commit that switches
> it to a good state and later you merge a bad-state branch and you have a
> bad state again. It is not made for that use-case, I think.

Correct. The assumption of bisection is that there is only one 
transition between GOOD and BAD. By violating that assumption, anything 
can happen.

-- Hannes