Re: git-rerere observations and feature suggestions

[Ingo Molnar <mingo@elte.hu>]

* Ingo Molnar <mingo@elte.hu> wrote:

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

some hard numbers. Doing a scripted loop of 80 git-merges is 16.2 
seconds:

 earth4:~/tip> time ( for N in $(cat 11 12 13 14); do git-merge $N; done )
 [...]
 Already up-to-date.

 real    0m16.211s
 user    0m10.719s
 sys     0m5.604s

doing the octopus merge of 4x 20 branch octopus merges is 11.6 seconds:

 earth4:~/tip> time ( for N in 1 2 3 4; do git-merge $(cat 1$N); done )
 Already up-to-date. Yeeah!
 Already up-to-date. Yeeah!
 Already up-to-date. Yeeah!
 Already up-to-date. Yeeah!

 real    0m11.580s
 user    0m8.617s
 sys     0m2.895s

a 40% speedup - and would be another 10% faster with an order-of-80 
merge as well i think. Not to be sniffed at.

	Ingo