The mystery of the missing commit across merges

master----\----commit A----cherry-picked changesets from topic---commit B--\----commit C----merge---           \                                                                \              /            topic-----------------------------------------------------------merge---------/                                                                            ~~~~~                                                                              ^                                                                              + here you merged B in topic

There is a merge already in topic that has commit B as parent. So B is fully merged in topic and won't be merged anywhere anymore.

Since you don't have the changes in topic, you apparently reverted them on topic, either in the merge itself or in a following commit. Such reversal is a regular commit for the merge algorithm and it's not merged into master. So when you merge topic into master, this commit's changes will be merged, reverting commit B.

To get the changes from B back, you have to either:

• Find and revert the reversal of B's changes on topic.
• Cherry-pick B (git cherry-pick B) on topic.
• Redo the merge, rebase topic after the merge on the new merge and forget the original branch, but as that involves rewinding you can only do that if you control all repositories that have the branch.

How the changes might have been reversed without you realizing it? If you are merging and get conflicts, you might resolve them sloppily using "local" thinking that you don't need these changes there yet. But from Git's (or any other version control system's for that matter; 3-way merge works the same in all of them) point of view you've seen the changes and rejected them, so you won't get them again, ever, unless you manually re-apply them.

The conflict might have easily been caused by the earlier cherry-picks. While the algorithm won't declare conflict if both sides look the same and thus if you cherry-pick and than merge, it will declare conflict if you modify the cherry-picked code on one side. Say you have:

----\-- A -------- B' -- B2 --\     \                         \      D -- B -- E -----------merge

where B' picks B and B2 modifies the same code that B did. In that case the merge will see that one side did B and the other side did B2, because the cherry-pick is hidden by B2 and will thus declare conflict between B and B2. And if you don't carefuly look at the history, you may easily resolve this wrong. You can avoid the problem if when picking a commit you carefuly merge the target branch into the source one like this:

----\-- A --------\- B' -\- B2 --\     \             \      \       \      D -- B -- E --m1-----m2----merge

where m1 is normal merge with no cherry-pick involved and m2 is resolved with local version, because it only has the cherry-picked changes on remote. That will ensure further merges will work correctly.

It should actually be possible to write a merge strategy for git to do this automatically.

Not sure why B isn't there, but I would recommend rebasing topic on top of master instead of merging master into topic.

Your cherry-picked commits are duplicated into master, and that doesn't play well when merging master into a branch (topic) with those same commits already present.
This is different when you rebase topic on top of master: any duplicate commit is not replayed.

Of course, the issue with rebase is that is changes topic SHA1, which is problematic if you had already pushed topic to an upstream repo (and other people have already pulled topic).

In general, as illustrated in "What is the right git workflow with shared feature branches?", you would want to avoid "back-merge" (master to topic) and use mainly merges in one way only (topic to master).