* Ingo Molnar <mingo@xxxxxxx> wrote:
> > 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
