mirrors/jgit - jgit - source @ dussan.org

Robin Stocker 7dc8a4f089 Fix exception on conflicts with recursive merge 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>	il y a 10 ans
..
jgit	Fix exception on conflicts with recursive merge	il y a 10 ans

Robin Stocker 7dc8a4f089 Fix exception on conflicts with recursive merge

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>

il y a 10 ans

jgit

Fix exception on conflicts with recursive merge

il y a 10 ans