Re: "git bisect run make" adequate to locate first unbuildable commit?
- From
SZEDER Gábor <szeder.dev@gmail.com>
- Date
- Feb 12, 2018, 13:05 UTC
- Message-ID
- <20180212130511.32620-1-szeder.dev@gmail.com>
- In-Reply-To
- <alpine.LFD.2.21.1802120512380.17034@localhost.localdomain>
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
badThen 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.