To undo revisions 118 and 120: svn up -r HEAD # get latest revision svn merge -c -120 . # undo revision 120 svn merge -c -118 . # undo revision 118 svn commit # after solving problems (if any) Also see the description in Undoing changes. Note the minus in the -c -120 argument. … Read more
That’s not possible – simply imagine what would happen if there was a conflict that couldn’t be resolved automatically. For the same reason you also can’t update branches that are not currently checked-out (even if a fast-forward was possible).
I’d do it with cherry-pick -n (–no-commit) which lets you inspect (and modify) the result before committing: git cherry-pick -n <commit> # unstage modifications you don’t want to keep, and remove the # modifications from the work tree as well. # this does work recursively! git checkout HEAD <path> # commit; the message will have … Read more
The problem is that a stash consists of two or three commits. When stashing, the modified working tree is stored in one commit, the index in one commit, and (if using the –include-untracked flag) any untracked files in a third commit. You can see this if you use gitk –all and do a stash. stash@{0} … Read more
cherry-pick Unless I have misled myself, then if you do “git cherry-pick <commit C>”, then you get: LOCAL: the commit you’re merging on top of (ie the HEAD of your branch) REMOTE: the commit you’re cherry picking (i.e. <commit C>) BASE: the parent of the commit you’re cherry-picking (ie C^, ie the parent of C) … Read more
You are trying to cherry-pick a merge. A merge is build up from at several parents. You have to supply the parent id to the merge. You have to supply any of the followings: -m parent-number / –mainline parent-number Usually you cannot cherry-pick a merge because you do not know which side of the merge … Read more
What I do in this case is use interactive rebase. At your HEAD, create your branches A, B, and C. Also create a “backup” branch (you could name it backup) in case things go wrong and you need your original HEAD back. git branch feature-a git branch feature-b git branch feature-c git branch backup-before-rebase Then, … Read more
Yes: git checkout -b mergebranch B git cherry-pick D
My understanding based off this answer is that parent 1 is the branch being merged into, and parent 2 is the branch being merged from. So in your case, parent 1 is A, and parent 2 is B. Since a cherry-pick is really applying the diff between two commits, you use -m 1 to apply … Read more
Before proceeding: Install a proper mergetool. On Linux, I strongly suggest you to use meld: sudo apt-get install meld Configure your mergetool: git config –global merge.tool meld Then, iterate in the following way: git cherry-pick …. git mergetool git cherry-pick –continue