From: SZEDER Gábor Date: Mon, 12 Feb 2018 13:05:11 GMT Subject: Re: "git bisect run make" adequate to locate first unbuildable commit? Message-ID: <20180212130511.32620-1-szeder.dev@gmail.com> In-Reply-To: > > 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 > and , then i've always assumed that what i'm after is a commit > for which: > > 1) is reachable from > 2) is reachable from > > this seems fairly obvious. Well, maybe _you_ are after such a commit, but bisect is after a commit for which 1) is reachable from (i.e. the same as your first point) 2) is not reachable from (which is not the same as your second point, notably when it comes to commits on side branches that branched off before and got merged later). > now, as you suggest, it's possible that the > "bug" was introduced on a feature branch that bypasses my choice of > but, at *some* point, that feature branch would have to be > merged to the point where it was now reachable from and, in the > context of bisection, *that* merge commit would represent where the > bug was introduced, no? No. Consider this piece of history: 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.