When someone has cherry-picked from my git commits and made commits of their own, how do I merge?

Question

Suppose I fork someone's git repo and make commits A, B, C, and D. The persom who I forked from then cherry-picks A and C, which therefore become A' and C'. He also makes commits X, Y, and Z of his own. So after all this, my branch has A B C D, and his has A' C' X Y Z. Assume that both branches are published, so rebase is not an attractive option. Also assume that X Y Z don't conflict with any of A B C D. How do I merge these two branches in a useful way? Should I simply merge and then manually resolve everything? Is there anything I can do about duplicate commit messages in the log of the merged head? Are these two branches doomed to sync only by cherry-picking each other's commits from now on?

Answer 1

A straight merge should work. Git should notice the identical change sets and will not attempt to merge A/A' or C/C'. If X, Y, or Z touched the same code that A'/C' changed, you may have to resolve conflicts there, especially if B or D touched the same code.

You can always git merge --no-commit and inspect the result to see if it's what you expected.

Answer 2

In case there are no conflicts, a straight merge is obvious. If there are conflicts though...

You could merge his C' first, any conflicts during this stage are from re-applying your own changes, if they are non-trivial or because they are applied a bit out of order. Can happen if your C builds up on B and his C' was not a clean copy, or if any of B C D builds up on A so reapplying his A' no longer is obvious no-op, etc.

You could skip detailed conflict investigation and just accept your version, manually or:

git merge --strategy=ours C'

Then merge the rest, paying more attention to conflicts there. If his X Y Z indeed don't touch A B C D stuff, this should go without conflicts. If he made something weird or wrong during merging C as C', and you discarded it when merging C', it can come back and bite you here or any time in the future though.