From: rsbecker@nexbridge.com
Date: Sun, 18 Dec 2022 14:10:39 GMT
Subject: RE: https://github.com/rust-lang/rust is not bisectable
Message-ID: <00c701d912ea$85527080$8ff75180$@nexbridge.com>
In-Reply-To: <20221218105239.GD3411@szeder.dev>

On December 18, 2022 5:53 AM, SZEDER Gábor wrote:
>On Sun, Dec 18, 2022 at 01:03:54PM +0300, Askar Safin wrote:
>> SZEDER Gábor, yes, in this particular case this helps.
>
>Not just in this particular case, but this solves a general issue of bisecting non-
>linear histories that is the file/testcase/whatever of interest is not present in all
>candidate revisions in the range '^good bad'.
>
>> (But
>> I still wonder how to tell git-bisect to ignore commits, which are not
>> descendants of good commit.)
>
>In general you do not want to tell that to bisect, because any one of them could
>have introduced the change you are looking for.  Consider the following piece of
>history, where commits 'm<N>' are on the master branch, 'b<N>' are on a
>different branch, and the commit marked with C made a buggy change, and
>commits marked with G and B are the ones you marked as good and bad you
>started the bisection.
>
>            (G)            (M)  (B)
>  m1---m2---m3---m4---m5---m6---m7
>        \                 /
>         b1---b2---b3---b4
>                   (C)
>
>If bisect were to ignore commits "which are not descendants of good commit",
>then it wouldn't look at any of the 'b<N>' commits made on the side branch.  It
>would only look at commits m{3,4,5,6,7}, and thus report m6 as the first bad
>commit, which is clearly not the case.

Could you not use bisect skip to ignore the commits that cannot be tested?