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>

org.eclipse.jgit/src/org/eclipse/jgit/merge/ResolveMerger.java

@@ -90,6 +90,7 @@ import org.eclipse.jgit.treewalk.CanonicalTreeParser;
 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 @@ public class ResolveMerger extends ThreeWayMerger {
 		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;