* Ingo Molnar <mingo@xxxxxxx> wrote:
> So i guess it's better to just create a separate
> .git/refs/merge-cache/ hierarchy with timestamps of last merged
> branches and their head sha1 ... but maybe i'm banging on open doors?
here's the git-fastmerge script i've whipped up in 10 minutes. It does
the trick nicely for me:
first run:
real 0m53.228s
user 0m41.134s
sys 0m11.405s
second run:
real 0m2.751s
user 0m1.280s
sys 0m1.491s
or a 20x speedup. Yummie! :-)
It properly notices when i commit to a topic branch, and it maintains a
proper matrix of <A> <- <B> merge timestamps. It even embedds the sha1's
in the timestamp path so it should be quite complete. It should work
fine across resets, re-merges, etc. too i think. It should work well
with renamed branches as well i think. (although i dont do that all that
often)
In fact even if i delete the whole .git/mergecache/ hierarchy and run a
'cold' merge, it's much faster:
real 0m32.129s
user 0m24.456s
sys 0m7.603s
Because many of the branches have the same sha1 so it's already
half-optimized even on the first run.
Much of the remaining 2.7 seconds overhead comes from the git-log runs
to retrieve the sha1s, so i guess it could all be made even faster.
Now this scheme assumes that there's a sane underlying filesystem that
can take these long pathnames and which has good timestamps (which i
have, so it's not a worry for me).
Hm?
Ingo
-----------------{ git-fastmerge }--------------------->
#!/bin/bash
usage () {
echo 'usage: git-fastmerge <refspec>..'
exit -1
}
[ $# = 0 ] && usage
BRANCH=$1
MERGECACHE=.git/mergecache
[ ! -d $MERGECACHE ] && { mkdir $MERGECACHE || usage; }
HEAD_SHA1=$(git-log -1 --pretty=format:"%H")
BRANCH_SHA1=$(git-log -1 --pretty=format:"%H" $BRANCH)
CACHE=$MERGECACHE/$HEAD_SHA1/$BRANCH_SHA1
[ -f "$CACHE" -a "$CACHE" -nt .git/refs/heads/$BRANCH_SHA1 ] && {
echo "merge-cache hit on HEAD <= $1"
exit 0
}
git-merge $1 && {
mkdir -p $(dirname $CACHE)
touch $CACHE
}
--
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
