Let’s return to the situation from Stop cherry-picking, start merging, Part 9: Chasing the commit. To recap, you have a master branch, a child branch (victim), and a grandchild branch (feature). You have a change in the grandchild (feature) branch that you want to move to the master branch, but in a way that will not cause problems when the feature branch merges back into the victim branch, and the victim branch merges back into the master branch. We saw that in order to do this safely, you need to “chase the commit” into the branch that has carried the change closest to the ultimate destination.¹

But there may be policy in your way. For example, suppose that the original commit has merged as far as the victim branch, so that would be the correct destination for the second half of the merge-pair. But there is a policy that direct commits into the victim branch are forbidden or at least heavily restricted. What can you do?

If the commit you are chasing already took the train to another branch, you can take the same scheduled train, just on another day.

Commit the merge into your feature branch and wait for the next train from your feature branch to the victim branch. Keep watching the train schedules until your merge commit finally catches up to the original commit. Once that’s done, you can commit the other merge into the final destination branch.

Waiting for the merge commit to catch up to the original commit may take a long time. If you are impatient (say, because the problem in master requires an urgent solution), you may be forced to just do the straight cherry-pick and deal with the consequences.

¹ Note that this scenario is relevant only if you are cherry-picking between two branches that will eventually merge. If this doesn’t match your team’s workflow, then the entire exercise is moot.