From: Johannes Sixt <j6t@kdbg.org>
Date: Sat, 22 Apr 2017 13:37:29 GMT
Subject: Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)
Message-ID: <a9685abc-50ad-3ee6-3384-0e043d205612@kdbg.org>
In-Reply-To: <CAP8UFD19DVqQLHBta74uLcFPwJaRUKF8Ppmnhct5ub=OkKSqCQ@mail.gmail.com>

Am 21.04.2017 um 14:29 schrieb Christian Couder:
> First bisect should ask you to test merge bases only if there are
> "good" commits that are not ancestors of the "bad" commit.

That's a tangent, but I have never understood why this needs to be so. 
Consider this:

     o--o--o--o--o--o--o--o--B
    /           /
  -o--o--o--o--g--o--o--o--o--G

When I mark B as bad and G as good, why would g have to be tested first? 
This is exactly what I do when I bisect in Git history: I mark the 
latest commits on git-gui and gitk sub-histories as good, because I know 
they can't possibly be bad. (In my setup, these two histories are ahead 
of pu and next.)

-- Hannes