Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]