On 2 June 2011 11:32, Carlos Martín Nieto <carlos@xxxxxxxxxx> wrote: > On Thu, Jun 02, 2011 at 11:17:41AM +0100, Howard Miller wrote: >> Trying to explain this as concisely as possible. >> >> I started with the following branches (names changed to protect the guilty)... >> >> * clientA >> * clientB >> >> both have a common ancestry.... >> >> I then checked out clientB created a new branch clientB_patch and did >> a load of work and commits. >> >> However, I actually wanted all those commits to apply to clientA >> branch instead so.... >> >> git checkout clientA >> git checkout -b clientA_patch (to ensure I didn't wreck original branch) >> git rebase --onto clientA_patch clientB clientB_patch > > The man page for git-rebase covers this exact situation (around line > 88 in my version) . In its case, it's > > git rebase --onto master next topic > > which translates to your case as > > git rebase --onto clientA clientB clientB_patch > Thanks. That's what I said (except I added an extra branch onto ClientA because I interpreted the instructions - wrongly - to say that ClientA would change). However, I've just realised the bit I missed. I still need to do a (fast forward) merge to get my ClientA_patch branch to actually reflect the changes. I can't help thinking that (although the diagrams are perfectly correct) that a line to the effect in the manpage might have saved some thinking time :) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html