Why does this cherry pick result in a merge conflict

Question

Edit: I added some Information I thought to be unnecessary, but is not. I have two branches, A and B. After making three commits in A that changes file.c I want to cherry-pick them into B, there is also a file.h which was changed in A~1

> git cherry-pick A~2
Success
> git cherry-pick A~1
error: could not apply 81e0723... 
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
> git status
You are currently cherry-picking commit 81e0723.
Unmerged paths:
(use "git add <file>..." to mark resolution)

  both modified:   some/unrelated/file.txt
  both modified:   file.c

Now when looking at some/unrelated/file.txt it contains the changes to file.h somewhere right in the middle. So this looks like a bug in git. So I will now undo the changes some/unrelated/file.txt manually and add them to file.h.

Answer 1

It's possible the cherry-pick is changing a function that had also been changed earlier in B's history, so the changes specifically in A~1 are to lines that already looked different from what's in the B version and git can't see where in B the cherry-pick's changes apply.

It's also possible that the context git finds for the changes has evil twins lying in wait elsewhere in the code (say, multiple lines with nothing but standalone closing braces), and other changes have put the real corresponding original in your code far enough from where it was in A~1^ that the hunt for the context in B finds something else instead. The manual suggests aborting the cherry-pick and retrying with git cherry-pick -Xpatience might be enough to avoid trouble with those, that spends an ordinarily-unreasonable amount of time trying to avoid getting lost in a sea of braces. Here's probably a good place to start if you want details on how that really works.

Answer 2

Cherry picking is no different than applying a set of patches in order (with the benefit of getting previous commit messages). This necessarily results in new blobs--which you can verify by noting that he commit sha's are different.

When merge time comes, git now thinks it's looking at a different history, because technically it is, and hence a merge conflict.