On Sun, Oct 26, 2014 at 4:19 PM, Andreas Schwab <sch...@linux-m68k.org> wrote: > Henning Moll <newssc...@gmx.de> writes: > >> 1. For P, A is the nearest prior commit on 'master' >> 2. on master: git rebase -i A^ >> 3. change A from pick to edit. save. quit >> 4. git merge P >> 5. git rebase --continue >> >> From the perspective of 'master' this worked. But as all of the commits >> have been rewritten, the branches b1 and b2 no longer refer to >> 'master'. Branch b2, for example, still branches off at B and not B'. > > You only rebased master, so b1 and b2 were unchanged. If you want to > change b1 and b2 you have to rebase them as well.
Yeah. Henning, when interactively rebasing, in our editor, you should have something like: pick A pick P pick B pick Q pick C pick D pick R pick E which should work without any conflict. And then you can rebase the b1 and b2 branches on the resulting branch. Best, Christian. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
