Branch A has commits (X,Y) that also need to be in Branch B. The cherry-pick operations should be done in the same chronological order that the commits appear in Branch A.
cherry-pick
does support a range of commits, but if you have merge commits in that range, it gets really complicated
git checkout branch-B
git cherry-pick X
git cherry-pick Y
Branch A has a series of commits (X..Y) that need to be moved to branch B. For this case, you'll need to specify the commit before the initial commit you're interested in order for it to be included. Example: you want commits B..D from (...A->B->C->D-E->...) you would use "A" as the starting commit. You'll also need the commit SHA for the HEAD of the branch you are transferring to.
git checkout branch-B
git log # Note the SHA of most recent commit (M)
git rebase --onto M <commit before X> Y
git rebase HEAD branch-B
Sorry, but this makes no sense. It still needs some clarification. And what really drives me crazy, is that if you don't do this command exactly right, you can create a complete mess that will take hours of cherry-picking and searching through the reflog to undo. So it's not like you can experiment.
Where are commits X through Y in relation to commits A through E ? You're referring to Branch A and commit A. Are they the same? Where did branch B come from? Is it related to branch A or commit B? or does that not matter?
OK, you checkout branch B. Now rebase "onto" it the commits X through Y.
In your example, we're interested in X and Y. So we find "M" which is the "most recent commit". You say the command is:
so that's:
But since we just did a checkout of branch B, why isn't M == HEAD? Or why not
which is (according to the documentation) the save as:
which is the same as
Or ... am I missing something? If not, the example is simply: