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

From: Robert P. J. Day <rpjday@crashcourse.ca>
Date: Feb 12, 2018, 10:19 UTC
Message-ID: <alpine.LFD.2.21.1802120512380.17034@localhost.localdomain>
In-Reply-To: <7135CFE5288C49EEA02785C1F407B46D@PhilipOakley>

On Fri, 9 Feb 2018, Philip Oakley wrote:

Show 31 quoted lines

> 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