public Class NameConflictTreeWalk

Due to the way a Git tree is organized the standard org.eclipse.jgit.treewalk.TreeWalk won't easily find a D/F conflict when merging two or more trees together. In the standard TreeWalk the file will be returned first, and then much later the directory will be returned. This makes it impossible for the application to efficiently detect and handle the conflict.

Using this walk implementation causes the directory to report earlier than usual, at the same time as the non-directory entry. This permits the application to handle the D/F conflict in a single step. The directory is returned only once, so it does not get returned later in the iteration.

When a D/F conflict is detected org.eclipse.jgit.treewalk.TreeWalk#isSubtree() will return true and org.eclipse.jgit.treewalk.TreeWalk#enterSubtree() will recurse into the subtree, no matter which iterator originally supplied the subtree.

Because conflicted directories report early, using this walk implementation to populate a org.eclipse.jgit.dircache.DirCacheBuilder may cause the automatic resorting to run and fix the entry ordering.

This walk implementation requires more CPU to implement a look-ahead and a look-behind to merge a D/F pair together, or to skip a previously reported directory. In typical Git repositories the look-ahead cost is 0 and the look-behind doesn't trigger, as users tend not to create trees which contain both "foo" as a directory and "foo.c" as a file.

In the worst-case however several thousand look-ahead steps per walk step may be necessary, making the overhead quite significant. Since this worst-case should never happen this walk implementation has made the time/space tradeoff in favor of more-time/less-space, as that better suits the typical case.