docs: explain why reverts are not always applied on merge
authorbrian m. carlson <sandals@crustytoothpaste.net>
Sun, 20 Sep 2020 23:22:30 +0000 (23:22 +0000)
committerJunio C Hamano <gitster@pobox.com>
Mon, 21 Sep 2020 04:29:02 +0000 (21:29 -0700)
commit409f066716598d5050c34b7bb0e6859940428dcf
tree6c8ca42b372e3681b8c1d79f6568bc7296dec754
parent5065ce412ef083a02288c1972ea3d07423cace0e
docs: explain why reverts are not always applied on merge

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>
Documentation/gitfaq.txt