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 25.04.2017 um 08:52 schrieb Junio C Hamano:
Johannes Sixt <j6t@xxxxxxxx> writes:

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

I think it is sort-of unfair to blame bisect for that.  It talks
more about how "coolest merge evar!" cross project merges are
unworkable in practice.

No, it has nothing to do with the "coolest merge ever". The same problem occurs when I'm working on a topic branch:

     A--....--B   <- topic
    /
 --g--....--G     <- integration branch ("good by default")

While fiddling with B, I find a bug and suspect it somewhere on the topic from A to B. When A has a change that causes a substantial or complete rebuild, testing g causes burden for no good reason.

But, as I said, this is a tangent. I have no mission to change git bisect.

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