summaryrefslogtreecommitdiff
path: root/Documentation/git-filter-branch.txt
diff options
context:
space:
mode:
authorLibravatar brian m. carlson <sandals@crustytoothpaste.net>2020-09-20 23:22:30 +0000
committerLibravatar Junio C Hamano <gitster@pobox.com>2020-09-20 21:29:02 -0700
commit409f066716598d5050c34b7bb0e6859940428dcf (patch)
tree6c8ca42b372e3681b8c1d79f6568bc7296dec754 /Documentation/git-filter-branch.txt
parentdocs: explain why squash merges are broken with long-running branches (diff)
downloadtgif-409f066716598d5050c34b7bb0e6859940428dcf.tar.xz
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>
Diffstat (limited to 'Documentation/git-filter-branch.txt')
0 files changed, 0 insertions, 0 deletions