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

From: Ingo Molnar <mingo@elte.hu>
Date: Jul 23, 2008, 15:06 UTC
Message-ID: <20080723150621.GA8499@elte.hu>
In-Reply-To: <20080723145622.GA23440@elte.hu>

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

Show 13 quoted lines

> > Shouldn't this be:
> > 
> > [ -f "$CACHE" -a "$CACHE" -nt .git/refs/heads/$BRANCH ] && {
> > 
> > ?
> 
> yeah, i just figured it out too ... the hard way :)
> 
> Updated script below. This works fine across resets in the master 
> branch.
> 
> While it's fast in the empty-merge case, it's not as fast as i'd like 
> it to be in the almost-empty-merge case.

When i update a topic branch, i first get a relatively fast run:

  earth4:~/tip> time todo-merge-all
  merging all branches ...
  Auto-merged arch/x86/kernel/genx2apic_uv_x.c
  Merge made by recursive.
   arch/x86/kernel/genx2apic_uv_x.c |    1 -
   1 files changed, 0 insertions(+), 1 deletions(-)
  ... merge done.

  real    0m6.625s
  user    0m3.740s
  sys     0m2.563s

Then on the next run it's slower:

  earth4:~/tip> time todo-merge-all
  merging all branches ...
  ... merge done.

  real    0m30.823s
  user    0m23.403s
  sys     0m7.545s

that's unfortunate. The freshly updated topic branch was at the end of the run, now all other topic branches will have to run slow at least once until they become cached again.

Perhaps the cache should update all other current topics to the new sha1, to establish the fact that they were not merged this time. (and that they are still not to be merged)

(It's still much faster than completely uncached though, because of the overlap in sha1's.)

Third (empty) run is fast again, because it's fully cached:

  earth4:~/tip> time todo-merge-all
  merging all branches ...
  ... merge done.

  real    0m3.036s
  user    0m1.360s
  sys     0m1.782s

But it would be nice if the cache worked more intelligently in the one-topic-updated-only case as well.

	Ingo