Browse Source
When there are conflicts with a recursive merge, the conflicting paths are stored in unmergedPaths (field in ResolveMerger). Later, when the MergeResult is constructed in MergeCommand, getBaseCommit is called, which computes the merge base a second time. In case of RecursiveMerger, getBaseCommit merges the multiple merge bases into one. It does this not by creating a new ResolveMerger but instead calling mergeTrees. The problem with mergeTrees is that at the end, it checks if unmergedPaths is non-empty and returns false in that case. Because unmergedPaths was already non-empty because of the real merge, it thinks that there were conflicts when computing the merge base again, when there really were none. This can be fixed by storing the base commit when computing it and then returning that instead of computing it a second time. Note that another possible fix would be to just use a new ResolveMerger for merging the merge bases instead. This would also remove the need to remember the old value of dircache, inCore and workingTreeIterator (see RecursiveMerger#getBaseCommit). Bug: 419641 Change-Id: Ib2ebf4e177498c22a9098aa225e3cfcf16bbd958 Signed-off-by: Robin Stocker <robin@nibor.org>stable-3.3
Robin Stocker
11 years ago
6 changed files with 72 additions and 27 deletions
Loading…
Reference in new issue