Why doesn't git cherry-pick override modification in current branch if their is different?

Question

Look, I make a modification in a branch and then pick a commit from a similar branch, which does not have this modification. I wonder if modification must be rolled back or

Answer 1

This is because the -Xtheirs part of git cherry-pick -Xtheirs only says what to do with conflicting changes, and there are no conflicting changes between the two commits in your last example. The merge strategy is recursive (the default in this case), and theirs is an option to this strategy.

If there was a strategy called theirs, then you would have gotten the result which you expected.

Now, there is no theirs strategy, but there is an ours strategy that can demonstrate the point. Instead of git cherry-pick -Xtheirs C, try git cherry-pick --strategy=ours C and see what happens. It will effectively ignore the changes from C and say that there is nothing to commit. This strategy is of course useless when cherry-picking, but it may help to understand.

To achieve what you really wanted in the first place, here is one way to do it:

git checkout A
git read-tree -m -u C
git commit --no-edit -c C

More information about merge strategies can be found in man git-merge.

Answer 2

From what I got on freenode#git, people say that in contrast to rebase, picking works with updates done by picked commit alone, it does not look at cumulative changes since the common root. This means that since B has introduced abc file, file will be re-introduced when picked on top of A and, thus overwriting the whole file. C however introduces only a small change in the file and therefore will leave A modification intact.