The interactive rebase command was originally designed to handle individual patch series. As such, it makes sense to exclude merge commits from the todo list, as the developer may have merged the then-current master while working on the branch, only to rebase all the commits onto master eventually (skipping the merge commits).
CONFLICT (rename/rename): Rename "will-be-renamed.txt"->"new-name-1.txt" in branch "HEAD" rename "will-be-renamed.txt"->"new-name-2.txt" in "branch2"
Automatic merge failed; fix conflicts and then commit the result.
If you want to keep one file, say new-name-2.txt:
git add new-name-2.txt
git rm new-name-1.txt will-be-renamed.txt
git commit
git revert -m 1 <merge-commit>
With ‘-m 1’ we tell git to revert to the first parent of the mergecommit on the master branch. -m 2 would specify to revert to the first parent on the develop branch where the merge came from initially
(lieber vorher prüfen welcher branch welcher ist)
git merge -s ours branch1
The Ours strategy operates on multiple N number of branches. The output merge result is always that of the current branch HEAD. The "ours" term implies the preference effectively ignoring all changes from all other branches. It is intended to be used to combine history of similar feature branches.
With Subversion 1.5 or later the merge is recorded on your local working copy in the svn:mergeinfo property. So this information is not lost.
You can see the merged revisions if you use svn log -g
Backout is basically four steps rolled into one:
hg update -C -r <rev-to-backout>
hg revert --all -r <parent of rev-to-backout>
hg commit
hg update -C -r <startrev>
There's a fifth step that is done automatically if you specify --merge :
hg merge (merges <startrev> with the newly committed rev from 3.)