Martin von Zweigbergk <martinvonz@xxxxxxxxx> writes:
> Although the subject line of 613f027 (read-tree -u one-way merge fix
> to check out locally modified paths., 2006-05-15) mentions "read-tree
> -u", it did not seem to check whether -u was in effect. Not checking
> whether -u is in effect makes e.g. "read-tree --reset" lstat() the
> worktree, even though the worktree stat should not matter for that
> operation.
>
> This speeds up e.g. "git reset" a little on the linux-2.6 repo (best
> of five, warm cache):
>
> Before After
> real 0m0.288s 0m0.233s
> user 0m0.190s 0m0.150s
> sys 0m0.090s 0m0.080s
> ---
Sign-off?
I briefly discussed this with Martin in person and came to the same
conclusion. To me this looks like an obvious performance fix, but an
independent code audit catches our mistakes is of course welcomed.
Thanks.
> I am very unfamiliar with this part of git, so my attempt at a
> motivation may be totally off.
>
> I have another twenty-or-so patches to reset.c coming up that take the
> timings down to around 90 ms, but this patch was quite unrelated to
> that. Those other patches actually make this patch pointless for "git
> reset" (it takes another path), but I hope this is still a good change
> for other operations that use oneway_merge.
>
> unpack-trees.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 6d96366..61acc5e 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -1834,7 +1834,7 @@ int oneway_merge(struct cache_entry **src, struct unpack_trees_options *o)
>
> if (old && same(old, a)) {
> int update = 0;
> - if (o->reset && !ce_uptodate(old) && !ce_skip_worktree(old)) {
> + if (o->reset && o->update && !ce_uptodate(old) && !ce_skip_worktree(old)) {
> struct stat st;
> if (lstat(old->name, &st) ||
> ie_match_stat(o->src_index, old, &st, CE_MATCH_IGNORE_VALID|CE_MATCH_IGNORE_SKIP_WORKTREE))
--
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