Re: q: faster way to integrate/merge lots of topic branches?

From: Ingo Molnar <mingo@elte.hu>
Date: Jul 23, 2008, 14:02 UTC
Message-ID: <20080723140243.GA6678@elte.hu>
In-Reply-To: <488734D9.9070703@op5.se>

* Andreas Ericsson <ae@op5.se> wrote:

Show 31 quoted lines

> Ingo Molnar wrote:
>> I've got the following, possibly stupid question: is there a way to  
>> merge a healthy number of topic branches into the master branch in a  
>> quicker way, when most of the branches are already merged up?
>>
>> Right now i've got something like this scripted up:
>>
>>   for B in $(git-branch | cut -c3- ); do git-merge $B; done 
>>
>> It takes a lot of time to run on even a 3.45GHz box:
>>
>>   real    0m53.228s
>>   user    0m41.134s
>>   sys     0m11.405s
>>
>> I just had a workflow incident where i forgot that this script was  
>> running in one window (53 seconds are a _long_ time to start doing some 
>> other stuff :-), i switched branches and the script merrily chugged 
>> away merging branches into a topic branch i did not intend.
>>
>> It iterates over 140 branches - but all of them are already merged up.
>>
>
> With the builtin merge (which is in next), this should be doable with 
> an octopus merge, which will eliminate the branches that are already 
> fully merged, resulting in a less-than-140-way merge (thank gods...). 
> It also doesn't have the 24-way cap that the scripted version suffers 
> from.
>
> If it does a good job at your rather extreme use-case, I'd say it's 
> good enough for 'master' pretty soon :-)

hm, while i do love octopus merges [*] for release and bisection-quality purposes, for throw-away (delta-)integration runs it's more manageable to do a predictable series of one-on-one merges.

It results in better git-rerere behavior, has easier (to the human) conflict resolutions and the octopus merge also falls apart quite easily when it runs into conflicts. Furthermore, i've often seen octopus merges fail while a series of 1:1 merges succeeded.

What i could try is to do a speculative octopus merge, in the hope of it just going fine - and then fall back to the serial merge if it fails?

The git-fastmerge approach is probably still faster though - and certainly simpler from a workflow POV.

	Ingo

[*] take a look at these in the Linux kernel -git repo:

      gitk 3c1ca43fafea41e38cb2d0c1684119af4c1de547
      gitk 6924d1ab8b7bbe5ab416713f5701b3316b2df85b