From: "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxx>
>
> 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
