development/git
development/git
1
0
Fork 0
mirror of https://github.com/git/git synced 2024-08-25 02:35:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: explain why reverts are not always applied on merge

Browse source 
A common scenario is for a user to apply a change to one branch and
cherry-pick it into another, then later revert it in the first branch.
This results in the change being present when the two branches are
merged, which is confusing to many users.

We already have documentation for how this works in `git merge`, but it
is clear from the frequency with which this is asked that it's hard to
grasp.  We also don't explain to users that they are better off doing a
rebase in this case, which will do what they intended.  Let's add an
entry to the FAQ telling users what's happening and advising them to use
rebase here.

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 2020-09-20 23:22:30 +00:00 committed by Junio C Hamano
parent 5065ce412e
commit 409f066716
1 changed files with 21 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

21
Documentation/gitfaq.txt
View file

@ -273,6 +273,27 @@ original merge base.
As a consequence, if you want to merge two long-lived branches repeatedly, it's
best to always use a regular merge commit.
[[merge-two-revert-one]]
If I make a change on two branches but revert it on one, why does the merge of those branches include the change?::
By default, when Git does a merge, it uses a strategy called the recursive
strategy, which does a fancy three-way merge. In such a case, when Git
performs the merge, it considers exactly three points: the two heads and a
third point, called the _merge base_, which is usually the common ancestor of
those commits. Git does not consider the history or the individual commits
that have happened on those branches at all.
+
As a result, if both sides have a change and one side has reverted that change,
the result is to include the change. This is because the code has changed on
one side and there is no net change on the other, and in this scenario, Git
adopts the change.
+
If this is a problem for you, you can do a rebase instead, rebasing the branch
with the revert onto the other branch. A rebase in this scenario will revert
the change, because a rebase applies each individual commit, including the
revert. Note that rebases rewrite history, so you should avoid rebasing
published branches unless you're sure you're comfortable with that. See the
NOTES section in linkgit:git-rebase[1] for more details.
Hooks
-----