mirrors/git
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation: document pitfalls with 3-way merge

Browse Source 
Oftentimes people will make the same change in two branches, revert the change
in one branch, and then be surprised when a merge reinstitutes that change when
the branches are merged.  Add an explanatory paragraph that explains that this
occurs and the reason why, so people are not surprised.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
brian m. carlson
2013-12-08 20:40:27 +00:00
committed by Junio C Hamano
parent 2f93541d88
commit c566500032
1 changed files with 8 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
Documentation/merge-strategies.txt
View File

@ -113,3 +113,11 @@ subtree::
match the tree structure of A, instead of reading the trees at match the tree structure of A, instead of reading the trees at
the same level. This adjustment is also done to the common the same level. This adjustment is also done to the common
ancestor tree. ancestor tree.
With the strategies that use 3-way merge (including the default, 'recursive'),
if a change is made on both branches, but later reverted on one of the
branches, that change will be present in the merged result; some people find
this behavior confusing. It occurs because only the heads and the merge base
are considered when performing a merge, not the individual commits. The merge
algorithm therefore considers the reverted change as no change at all, and
substitutes the changed version instead.