Am 25.04.2017 um 04:00 schrieb Christian Couder:
On Sat, Apr 22, 2017 at 3:37 PM, Johannes Sixt <j6t@xxxxxxxx> wrote:
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?
It is because g could be bad if the bug has been fixed between g and G.
If this happens and we don't test g, we would give a wrong result.
Gah! So, a typical messy workflow "requires" this behavior. A clean
branchy workflow like Git's does not because we know that a breakage is
either on a topic branch, B, or a (the?) bad commit is an ancester of
(the integration branch) G.
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.)
Yeah, it is safe to do that in this case as we test the merge bases.
The idea of marking git-gui and gitk histories that none of their
commits is checked out: it erases all Git source code from the working
directory, and a later bisection step places all code back and it
requires a full build. Not a big deal with Git, but there are much
larger code bases.
The current bisect behavior makes this idea unworkable. For me, it was a
big step backwards when it was implemented. :-(
-- Hannes