mirror of
https://github.com/git/git
synced 2024-08-25 10:45:59 +00:00
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 <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit is contained in:
parent
2f93541d88
commit
c566500032
|
@ -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.
|
||||
|
|
Loading…
Reference in a new issue