Commit 468cd8f introduced a new merge driver that avoids conflicts during merges by adding to the DB all the entries that have been changed in at least one branch. This strategy solves perfectly the classic case of a conflict caused by two simultaneous additions to the same DB. However, if the same entry has been edited in both branches, this strategy will include in the final DB both versions. This is OK because no information is lost but there should be a way to warn the user about this problem.
For example when the branch with this diff
1p::abc:entry1
- 1p::def:entry2
+1p::c00:entryAAA
1p::bbb:entry3
is merged with the branch with this diff
1p::abc:entry1
- 1p::def:entry2
+1p::832:entryBBB
1p::bbb:entry3
the result DB will be
1p::abc:entry1
1p::c00:entryAAA
1p::832:entryBBB
1p::bbb:entry3
After the merge pw has no way to detect that two different entries (entryAAA and entryBBB) have replaced entry2.
One possible solution is to
- use
git merge-file without --union,
- find entries that are part of real conflicts,
- run
git merge-file --union,
- add
c (for conflict) to the version information field of the problematic entries.
Commit 468cd8f introduced a new merge driver that avoids conflicts during merges by adding to the DB all the entries that have been changed in at least one branch. This strategy solves perfectly the classic case of a conflict caused by two simultaneous additions to the same DB. However, if the same entry has been edited in both branches, this strategy will include in the final DB both versions. This is OK because no information is lost but there should be a way to warn the user about this problem.
For example when the branch with this diff
is merged with the branch with this diff
the result DB will be
After the merge
pwhas no way to detect that two different entries (entryAAAandentryBBB) have replacedentry2.One possible solution is to
git merge-filewithout--union,git merge-file --union,c(for conflict) to the version information field of the problematic entries.