Use ANY_DIFF filter in ResolveMerger only for bare repositories

As Chris pointed out change I822721c76c64e614f87a080ced2457941f53adcd
slowed down merge since ANY_DIFF filter is much less efficient than the
manual detection of diffs done in ResolveMerger.processEntry() since it
avoids unnecessary filesystem calls using the git index. Hence only set
the ANY_DIFF filter on bare repositories which don't have a working tree
to scan.

To test performance I used the setup described in Chris' comment on
change I822721c76c64e614f87a080ced2457941f53adcd and modified
ResolveMerger.mergeTrees() to not add the working tree in order to
simulate merging in a bare repository.

At least on Mac I couldn't detect a speedup, with and without the
ANY_DIFF filter merge test takes an average 0.67sec.

Change-Id: I17b3a06f369cee009490f54ad1a2deb6c145c7cf
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This commit is contained in:
Matthias Sohn 2015-04-13 01:01:13 +02:00
parent 4ac7cf003b
commit 8b9623511f
1 changed files with 5 additions and 1 deletions

View File

@ -90,6 +90,7 @@
import org.eclipse.jgit.treewalk.NameConflictTreeWalk;
import org.eclipse.jgit.treewalk.TreeWalk;
import org.eclipse.jgit.treewalk.WorkingTreeIterator;
import org.eclipse.jgit.treewalk.filter.TreeFilter;
import org.eclipse.jgit.util.FS;
import org.eclipse.jgit.util.TemporaryBuffer;
@ -1012,8 +1013,11 @@ protected boolean mergeTrees(AbstractTreeIterator baseTree,
tw.addTree(headTree);
tw.addTree(mergeTree);
tw.addTree(buildIt);
if (workingTreeIterator != null)
if (workingTreeIterator != null) {
tw.addTree(workingTreeIterator);
} else {
tw.setFilter(TreeFilter.ANY_DIFF);
}
if (!mergeTreeWalk(tw, ignoreConflicts)) {
return false;