Re: Does "git bisect" work for anyone?

["H.J. Lu" <hjl.tools@gmail.com>]

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.