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

["SZEDER Gábor" <szeder.dev@gmail.com>]

> > 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).

> 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.