From: brian m. carlson Date: Sun, 8 Dec 2013 20:40:27 +0000 (+0000) Subject: Documentation: document pitfalls with 3-way merge X-Git-Tag: v1.9-rc0~66^2 X-Git-Url: https://git.lorimer.id.au/gitweb.git/diff_plain/c5665000327388832fa8be0b3bf17669f672481b?hp=--cc Documentation: document pitfalls with 3-way merge 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 Signed-off-by: Junio C Hamano --- c5665000327388832fa8be0b3bf17669f672481b diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index 49a9a7d53f..fb6e593e7c 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -113,3 +113,11 @@ subtree:: match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common 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.