Re: "git bisect run make" adequate to locate first unbuildable commit?

["Robert P. J. Day" <rpjday@crashcourse.ca>]

On Fri, 9 Feb 2018, Philip Oakley wrote:

> From: "Robert P. J. Day" <rpjday@crashcourse.ca>
> > On Fri, 9 Feb 2018, Philip Oakley, CEng MIET wrote:
> (apologies for using the fancy letters after the name ID...)
> >
> >> From: "Robert P. J. Day" <rpjday@crashcourse.ca>
> >> >
> >> > writing a short tutorial on "git bisect" and, all the details
> >> > of special exit code 125 aside, if one wanted to locate the
> >> > first unbuildable commit, would it be sufficient to just run?
> >> >
> >> >  $ git bisect run make
> >> >
> >> > as i read it, make returns either 0, 1 or 2 so there doesn't
> >> > appear to be any possibility of weirdness with clashing with a
> >> > 125 exit code. am i overlooking some subtle detail here i
> >> > should be aware of? thanks.
> >>
> >> In the spirit of pedanticism, one should also clarify the word
> >> "first", in that it's not a linear search for _an_ unbuildable
> >> commit, but that one is looking for the transition between an
> >> unbroken sequence of unbuildable commits, which transitions to
> >> buildable commits, and its the transition that is sought. (there
> >> could be many random unbuildable commits within a sequence in
> >> some folks' processes!)
> >
> >  quite so, i should have been more precise.
> >
> > rday
>
> The other two things that may be happening (in the wider bisect
> discussion) that I've heard of are:

> 1. there may be feature branches that bypass the known good starting
>    commit, which can cause understanding issues as those side
>    branches that predate the start point are also considered
>    potential bu commits.

  ok, but let's make sure i understand what defines a possible commit
that "introduces" the bug. if i define two bisection commits <good>
and <bad>, then i've always assumed that what i'm after is a commit
<X> for which:

  1) <X> is reachable from <bad>
  2) <good> is reachable from <X>

this seems fairly obvious. now, as you suggest, it's possible that the
"bug" was introduced on a feature branch that bypasses my choice of
<good> but, at *some* point, that feature branch would have to be
merged to the point where it was now reachable from <bad> and, in the
context of bisection, *that* merge commit would represent where the
bug was introduced, no?

rday