[+cc Junio for cache-tree expertise]
On Thu, May 22, 2014 at 03:09:59PM -0400, Jeff King wrote:
> > > does show some improvement. Perhaps "git reset" is not writing out the
> > > cache-tree extension?
> [...]
>
> Possibly. There is a call to prime_cache_tree in builtin/reset.c, which
> looks like it should trigger during a "mixed" or "hard" reset (and
> without arguments, you should have a mixed reset). But it doesn't seem
> to get called. I haven't traced it further.
So here's what's happening. The prime_cache_tree call is in reset_index,
and was added by:
commit 6c52ec8a9ab48b50fc8bf9559467d5a4cf7eee3b
Author: Thomas Rast <trast@xxxxxxxxxxxxxxx>
Date: Tue Dec 6 18:43:39 2011 +0100
reset: update cache-tree data when appropriate
In the case of --mixed and --hard, we throw away the old index and
rebuild everything from the tree argument (or HEAD). So we have an
opportunity here to fill in the cache-tree data, just as read-tree
did.
Signed-off-by: Thomas Rast <trast@xxxxxxxxxxxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
But that was counteracted by:
commit 3fde386a40f38dbaa684c17603e71909b862d021
Author: Martin von Zweigbergk <martinvonz@xxxxxxxxx>
Date: Mon Jan 14 21:47:51 2013 -0800
reset [--mixed]: use diff-based reset whether or not pathspec was given
Thanks to b65982b (Optimize "diff-index --cached" using cache-tree,
2009-05-20), resetting with paths is much faster than resetting
without paths. Some timings for the linux-2.6 repo to illustrate this
(best of five, warm cache):
reset reset .
real 0m0.219s 0m0.080s
user 0m0.140s 0m0.040s
sys 0m0.070s 0m0.030s
These two commands should do the same thing, so instead of having the
user type the trailing " ." to get the faster do_diff_cache()-based
implementation, always use it when doing a mixed reset, with or
without paths (so "git reset $rev" would also be faster).
Timing "git reset" shows that it indeed becomes as fast as
"git reset ." after this patch.
Signed-off-by: Martin von Zweigbergk <martinvonz@xxxxxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
We never call reset_index now, because we handle it via diff. We could
call prime_cache_tree in this case, but I'm not sure if that is a good
idea, because it primes it from scratch (and so it opens up all those
trees that we are trying to avoid touching). I'm not sure if there's an
easy way to update it incrementally; I don't know the cache-tree code
very well.
-Peff
--
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