threads / discuss / 47797

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

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

## tl;dr

8 messages between Feb 9, 2018 and Feb 13, 2018.

replies: 7people: 5as markdown or json

Robert P. J. Day· Feb 9, 2018, 13:20 UTC · lore
  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
Christian Couder· Feb 9, 2018, 13:47 UTC · re: Robert P. J. Day · lore

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

On Fri, Feb 9, 2018 at 2:20 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
Show 10 quoted lines
>
>   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.
I think you are not overlooking anything.
Philip Oakley, CEng MIET· Feb 9, 2018, 20:57 UTC · re: Robert P. J. Day · lore

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

From: "Robert P. J. Day" <rpjday@crashcourse.ca>
Show 13 quoted lines
>
>  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!) -- Philip

Robert P. J. Day· Feb 9, 2018, 20:54 UTC · re: Philip Oakley, CEng MIET · lore

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

On Fri, 9 Feb 2018, Philip Oakley, CEng MIET wrote:
Show 21 quoted lines
> 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
Philip Oakley· Feb 9, 2018, 22:44 UTC · re: Robert P. J. Day · lore

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

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...)
Show 26 quoted lines
>
>> 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.
2. if you just want the first parent check for the bad commit point, that 
mark the second parents of merges as being good.

Also, I'd expect that the skipped commits aren't 'counted' (too hard?) for the bisect algorithm's reporting.

https://stackoverflow.com/questions/5638211/how-do-you-get-git-bisect-to-ignore-merged-branches contains a number of the ideas..

Philip
Robert P. J. Day· Feb 12, 2018, 10:19 UTC · re: Philip Oakley · lore

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

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
SZEDER Gábor· Feb 12, 2018, 13:05 UTC · re: Robert P. J. Day · lore

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

Show 14 quoted lines
> > 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.

Well, maybe _you_ are after such a commit, but bisect is after a commit <X> for which

  1) <X> is reachable from <bad> (i.e. the same as your first point)
  2) <X> is not reachable from <good> (which is not the same as your
     second point, notably when it comes to commits on side branches
     that branched off before <good> and got merged later).
Show 6 quoted lines
> 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?
No.  Consider this piece of history:
           <good>               <bad>
              v                   v
    --a---b---C---d---e---M---k---L--
       \                 /
        f---g---H---i---j
                ^
              first
               bad

Then the command 'git bisect start L C' will first consider the following as "possible commit that introduces the bug":

  d e f g H i j M k L

(IOW all commits listed by 'git log ^C L') and will then systematically narrow down until it will find commit H as the transition from good to bad.

Robert P. J. Day· Feb 13, 2018, 12:41 UTC · re: Philip Oakley · lore

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

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.

← back to recent threads