diff options
author | Christian Halstrick <christian.halstrick@sap.com> | 2014-07-18 11:04:33 +0200 |
---|---|---|
committer | Robin Stocker <robin@nibor.org> | 2014-07-25 03:32:38 -0400 |
commit | 0c4553d28a34dfb64f4af68032a9a33ca297975e (patch) | |
tree | 08eea10cb6b9aaf45a79c218d84ef7b90b9e46b6 /org.eclipse.jgit.test/org.eclipse.jgit.core--All-External-Tests (Java 6).launch | |
parent | cf9b01b09a320de4afb8da8f2ec5002fd0441831 (diff) | |
download | jgit-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