> > 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
       \                 /

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.

Reply via email to