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@xxxxxxxxxxxxxxxxxxxx> --- This is a documentation fix that I've been holding onto for a week or so. I noticed that a lot of people were surprised by this behavior, and figured it would be better to document it. I'm not sure that this is the right place for it, and I'm happy to take suggestions on how to improve the wording. Documentation/merge-strategies.txt | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index 49a9a7d..fb6e593 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. -- 1.8.5.1 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html