Re: Git bisect does not find commit introducing the bug
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Feb 18, 2017, 09:12 UTC
- 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:
Show 26 quoted lines
> 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