Re: git-rerere observations and feature suggestions

Ingo Molnar [off-list ref] writes:

* Ingo Molnar [off-list ref] wrote:

quoted

And while asking for an arm i'd also like to ask for a leg, if i may: 
i'd love it if a "slightly conflicting" octopus merge of 85 topic 
trees would not result in one huge conflict commit that merges 
together 1000 commits into a single commit ;-)

So right now in our -tip scripts work around this issue: we 
'serialize' the topic merges despite having very nice opportunities 
for higher-order octopus merges. The integration would be a lot faster 
if we could use octopus merges and automated git-rerere. (Octopus 
merges would look much nicer as well in graphical representation as 
well, which counts too :-) )

just to demonstrate it, i tried today to do an octopus merge of 87 topic 
branches:

git-merge build checkme core/checkme core/debugobjects core/futex-64bit 
core/iter-div core/kill-the-BKL core/locking core/misc core/percpu 
core/printk core/rcu core/rodata core/softirq core/softlockup 
core/stacktrace core/topology core/urgent cpus4096 genirq kmemcheck 
kmemcheck2 mm/xen out-of-tree pci-for-jesse safe-poison-pointers sched 
sched-devel scratch stackprotector timers/clockevents timers/hpet 
timers/hrtimers timers/nohz timers/posixtimers tip tracing/ftrace 
tracing/ftrace-mergefixups tracing/immediates tracing/markers 
tracing/mmiotrace tracing/mmiotrace-mergefixups tracing/nmisafe 
tracing/sched_markers tracing/stopmachine-allcpus tracing/sysprof 
tracing/textedit x86/apic x86/apm x86/bitops x86/build x86/checkme 
x86/cleanups x86/cpa x86/cpu x86/defconfig x86/delay x86/gart x86/i8259 
x86/idle x86/intel x86/irq x86/irqstats x86/kconfig x86/ldt x86/mce 
x86/memtest x86/mmio x86/mpparse x86/nmi x86/numa x86/numa-fixes x86/pat 
x86/pebs x86/ptemask x86/resumetrace x86/scratch x86/setup x86/smpboot 
x86/threadinfo x86/timers x86/urgent x86/urgent-undo-ioapic x86/uv 
x86/vdso x86/xen x86/xsave

it failed miserably:

 warning: ignoring 066519068ad2fbe98c7f45552b1f592903a9c8c8; cannot 
 handle more than 25 refs
 [...]
 fatal: merge program failed
 Automated merge did not work.
 Should not be doing an Octopus.
 Merge with strategy octopus failed.

this wasnt even for purposes of an integration run: all i wanted to do 
was to pick up 2-3 new commits i have queued into 2-3 topic branches, 
into the (throw-away) integration branch. All the other branches were 
unmodified and already merged into the integration branch.

Hence i believe that the suggestions above by Git that i'm doing 
something wrong are ... wrong :-)

My scripting around this would be a lot faster (less than 10 seconds 
runtime versus a minute currently) and more robust if we could do such 
higher-order octopus merges.

As a part of patch series introducing new fast-forward strategies
(--ff=never, --ff=only) there was patch which did merge reduction
before selecting merge strategy, by Sverre Hvammen Johansen
  "[PATCH 4/5] Head reduction before selecting merge strategy"
  http://thread.gmane.org/gmane.comp.version-control.git/80288/focus=80335
(I'm not sure if the link above is to nevest version of patch series).

It is now part of 'pu' branch, as commit 59171adb9c.  It didn't make
into 'next' as it conflict with builtin merge by Miklos Vajna, which
(as he wrote) also includes head reduction.

So you either would have to compile git from builtin-merge repository,
compile git from 'pu' or just use git-merge.sh from 'pu' branch, or
apply or cherry pick appropriate commit and compile git.

-- 
Jakub Narebski
Poland
ShadeHawk on #git