summaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.test/org.eclipse.jgit.core--All-External-Tests (Java 6).launch
diff options
context:
space:
mode:
authorChristian Halstrick <christian.halstrick@sap.com>2014-07-18 11:04:33 +0200
committerRobin Stocker <robin@nibor.org>2014-07-25 03:32:38 -0400
commit0c4553d28a34dfb64f4af68032a9a33ca297975e (patch)
tree08eea10cb6b9aaf45a79c218d84ef7b90b9e46b6 /org.eclipse.jgit.test/org.eclipse.jgit.core--All-External-Tests (Java 6).launch
parentcf9b01b09a320de4afb8da8f2ec5002fd0441831 (diff)
downloadjgit-0c4553d28a34dfb64f4af68032a9a33ca297975e.tar.gz
jgit-0c4553d28a34dfb64f4af68032a9a33ca297975e.zip
Fix RecursiveMerger's internal use of merge to find a merge base
When RecursiveMerger tried to determine a common base tree it was recursively tried to merge multiple common bases. But these intermediate merges which have just been done to determine a single common base for the final merge already filled some important fields (toBeCheckedOut, toBeDeleted, ...). These side effects of the intermediate merges led to wrong results of the final merge. One symptom was that after a recursive merge which should be succesful you could still see leftover files in the worktree: files which existed in the (virtual) common base but which don't exist anymore in the branches to be merged. The solution is easy: Clear the appropriate fields after common base determination and start the final merge with a clean state. Change-Id: I644ea9e1cb15360f7901bc0483cdb9286308c226 Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Diffstat (limited to 'org.eclipse.jgit.test/org.eclipse.jgit.core--All-External-Tests (Java 6).launch')
0 files changed, 0 insertions, 0 deletions