This was seen to happen in some invocations of git-log with a filtered
path. Only do it if we are not recursively descending, as otherwise we
mess with copy and rename detection in full tree moves.
We need to exclude times when FIND_COPIES_HARDER is enabled as the diff
machinery requires traversal of all files in this case to find copies
from files that did not change at all in the given revision.
Signed-off-by: Dan McGee <dpmcgee@xxxxxxxxx>
---
These next few patches are all derived from trying to make operations on this
repository a bit faster:
http://projects.archlinux.org/svntogit/packages.git/
As far as a different shape of repository, this one qualifies. Some stats from
after running `git gc --prune` and looking at things from count-objects among
others:
arch-packages linux-2.6
in-pack: 496718 1979274
size-pack: 112582 513977
ls | wc -l: 2401 34
ls-tree -r | wc -l 14039 36706
ls-tree -r -t | grep ' tree ' | wc -l
11211 2256
time git log -- zzzzz_not_exist >/dev/null
35.558s 0.976s
I didn't find some golden switch to turn that made things instantly fast, but
these patches did at least give some speedups. Suggestions/feedback/etc.
welcome. Most profiling was done with `valgrind --tool=callgrind` and then
using kcachegrind to chase down slow spots.
tree-diff.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/tree-diff.c b/tree-diff.c
index 76f83fc..ab90f1a 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -286,6 +286,9 @@ int diff_tree_sha1(const unsigned char *old, const unsigned char *new, const cha
unsigned long size1, size2;
int retval;
+ if (!DIFF_OPT_TST(opt, FIND_COPIES_HARDER) && !hashcmp(old, new))
+ return 0;
+
tree1 = read_object_with_reference(old, tree_type, &size1, NULL);
if (!tree1)
die("unable to read source tree (%s)", sha1_to_hex(old));
--
1.7.4.2
--
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