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

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

On Fri, 9 Feb 2018, Philip Oakley wrote:

Show 33 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.
> >> >
> >> > rday
> >>
> >> 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.

  ... snip ...

  sorry, i should have replied to this post since my last post
directly addresses this scenario -- i believe this is precisely what
you were suggesting:

               ... 50000 commits ... (feature branch)
             /                      ^
            /                        \
           v                          \
  A  <--  B <-- <GOOD> <-- D <-- E <-- F <-- <BAD>

i'm still curious ... if one doesn't get into skipping, what is the "git rev-list" command to identify all of the possible revisions to be tested here? isn't it just:

  $ git rev-list <BAD> ^<GOOD>

or was there somthing more subtle i was missing? sorry if someone already explained this, i'll go back later and read the replies in more excruciating detail.

rday

p.s. i'll take a closer look at the "--bisect*" options to "git rev-list" shortly.