diff mbox series

[2/3] docs: explain why reverts are not always applied on merge

Message ID 20200912204824.2824106-3-sandals@crustytoothpaste.net
State New
Headers show
Series FAQ entries for merges and modified files | expand

Commit Message

brian m. carlson Sept. 12, 2020, 8:48 p.m. UTC
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
merge, 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>
---
 Documentation/gitfaq.txt | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

Comments

Martin Ă…gren Sept. 13, 2020, 3:12 p.m. UTC | #1
On Sat, 12 Sep 2020 at 22:51, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> 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
> merge, which is confusing to many users.

s/merge/&d/

> +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.

Should this include the usual disclaimer about only rebasing a branch if
it hasn't been published or if you (and your team) is willing and able
to handle the fallout? I dunno. This piece of text is vague enough that
the reader will have to pick up the "rebase ... onto" keywords and
figure out the details some other way (and to be clear: I think that's a
good thing). I think that should be sufficient and they'll find the
disclaimer when they look up "rebase", if they don't already know it.


Martin
diff mbox series

Patch

diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt
index 550f4e30d6..154f0cce54 100644
--- a/Documentation/gitfaq.txt
+++ b/Documentation/gitfaq.txt
@@ -274,6 +274,25 @@  original merge base.
 As a consequence, if you want to merge two long-running branches, 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.
+
 Hooks
 -----