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

From: Johannes Sixt <j6t@kdbg.org>
Date: Apr 25, 2017, 18:26 UTC
Message-ID: <1336f7a6-4785-d60d-d100-df38e22aa9e8@kdbg.org>
In-Reply-To: <xmqqa875uggj.fsf@gitster.mtv.corp.google.com>

Am 25.04.2017 um 08:52 schrieb Junio C Hamano:

Show 14 quoted lines

> Johannes Sixt <j6t@kdbg.org> 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