Does "git bisect" work for anyone?

Does "git bisect" work for anyone?

[H.J. Lu]

On master branch, I got

$ git checkout d0e70c4189d5d6a6e63b85c1d3c10c74852173b4
Previous HEAD position was 5a805384b83 asan: readelf buffer overflow and abort
HEAD is now at d0e70c4189d Automatic date update in version.in
$ git bisect good
$ git checkout fe07b5721a64a84e36ec63e15638b87655faf1bf
Previous HEAD position was d0e70c4189d Automatic date update in version.in
HEAD is now at fe07b5721a6 gdb/testsuite: Update test pattern in
ptype-on-functions.exp
$ git bisect bad
Some good revs are not ancestors of the bad rev.
git bisect cannot work properly in this case.
Maybe you mistook good and bad revs?


-- 
H.J.

Re: Does "git bisect" work for anyone?

[Andreas Schwab]

On Okt 02 2020, H.J. Lu via Binutils wrote:

> On master branch, I got
>
> $ git checkout d0e70c4189d5d6a6e63b85c1d3c10c74852173b4
> Previous HEAD position was 5a805384b83 asan: readelf buffer overflow and abort
> HEAD is now at d0e70c4189d Automatic date update in version.in
> $ git bisect good
> $ git checkout fe07b5721a64a84e36ec63e15638b87655faf1bf
> Previous HEAD position was d0e70c4189d Automatic date update in version.in
> HEAD is now at fe07b5721a6 gdb/testsuite: Update test pattern in
> ptype-on-functions.exp
> $ git bisect bad
> Some good revs are not ancestors of the bad rev.

Git told you the reason.

$ git rev-list d0e70c4189d5d6a6e63b85c1d3c10c74852173b4..fe07b5721a64a84e36ec63e15638b87655faf1bf | wc -l
0
$ git rev-list fe07b5721a64a84e36ec63e15638b87655faf1bf..d0e70c4189d5d6a6e63b85c1d3c10c74852173b4 | wc -l
232

> git bisect cannot work properly in this case.
> Maybe you mistook good and bad revs?

If you want to find the commit where an issue is fixed, you need to mark
the commits that don't have the issue as bad and the the ones that have
the issue as good.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Does "git bisect" work for anyone?

[H.J. Lu]

On Fri, Oct 2, 2020 at 11:27 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>
> On Okt 02 2020, H.J. Lu via Binutils wrote:
>
> > On master branch, I got
> >
> > $ git checkout d0e70c4189d5d6a6e63b85c1d3c10c74852173b4
> > Previous HEAD position was 5a805384b83 asan: readelf buffer overflow and abort
> > HEAD is now at d0e70c4189d Automatic date update in version.in
> > $ git bisect good
> > $ git checkout fe07b5721a64a84e36ec63e15638b87655faf1bf
> > Previous HEAD position was d0e70c4189d Automatic date update in version.in
> > HEAD is now at fe07b5721a6 gdb/testsuite: Update test pattern in
> > ptype-on-functions.exp
> > $ git bisect bad
> > Some good revs are not ancestors of the bad rev.
>
> Git told you the reason.
>
> $ git rev-list d0e70c4189d5d6a6e63b85c1d3c10c74852173b4..fe07b5721a64a84e36ec63e15638b87655faf1bf | wc -l
> 0

How did this happen?  Joel, shouldn't git commit hook check non-empty
forward and backward git rev-list outputs to support git bisect?

> $ git rev-list fe07b5721a64a84e36ec63e15638b87655faf1bf..d0e70c4189d5d6a6e63b85c1d3c10c74852173b4 | wc -l
> 232
>
> > git bisect cannot work properly in this case.
> > Maybe you mistook good and bad revs?
>
> If you want to find the commit where an issue is fixed, you need to mark
> the commits that don't have the issue as bad and the the ones that have
> the issue as good.
>



-- 
H.J.

Re: Does "git bisect" work for anyone?

[Simon Marchi]

On 2020-10-03 9:57 a.m., H.J. Lu via Gdb wrote:
> On Fri, Oct 2, 2020 at 11:27 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>>
>> On Okt 02 2020, H.J. Lu via Binutils wrote:
>>
>>> On master branch, I got
>>>
>>> $ git checkout d0e70c4189d5d6a6e63b85c1d3c10c74852173b4
>>> Previous HEAD position was 5a805384b83 asan: readelf buffer overflow and abort
>>> HEAD is now at d0e70c4189d Automatic date update in version.in
>>> $ git bisect good
>>> $ git checkout fe07b5721a64a84e36ec63e15638b87655faf1bf
>>> Previous HEAD position was d0e70c4189d Automatic date update in version.in
>>> HEAD is now at fe07b5721a6 gdb/testsuite: Update test pattern in
>>> ptype-on-functions.exp
>>> $ git bisect bad
>>> Some good revs are not ancestors of the bad rev.
>>
>> Git told you the reason.
>>
>> $ git rev-list d0e70c4189d5d6a6e63b85c1d3c10c74852173b4..fe07b5721a64a84e36ec63e15638b87655faf1bf | wc -l
>> 0
>
> How did this happen?  Joel, shouldn't git commit hook check non-empty
> forward and backward git rev-list outputs to support git bisect?

What does that mean?  How can you have both forward and backward
rev-list non-empty?

It's just that you got the revs backwards.  By default, "good" must be
older than "bad".  If that's confusing, because you are investigating
when a fix was introduced (and therefore, your "bad" is older than your
"good"), you can change the terms to use something else than "good" and
"bad".  For example:

    $  git bisect start --term-old my_bad --term-new my_good
    $  git bisect my_bad fe07b5721a64a84e36ec63e15638b87655faf1bf
    $  git bisect my_good d0e70c4189d5d6a6e63b85c1d3c10c74852173b4
    Bisecting: 115 revisions left to test after this (roughly 7 steps)
    [e148b73013109517c4d179aa9ae5a50b6d1dd5b5] libctf: drop error-prone ctf_strerror

Simon