Hi Björn, First of all thank you very much for your quick reply (actually my thanks go to all that have replied so far). Note that at the moment it is just a brain exercise. We are currently using CVS (yes, I know) and want to switch to something else and I'm trying to push for git. During our discussions this scenario came up and I could not give a simple answer. That's why I thought I'd better ask the experts. > What's unusual there is that you merged from Mainline to Feature_A. > Usually, the history would look like this: > > o--o--o Release_1.0 > / \ \ > o-o-o--o--o-o-o-o-o-o---o--o Mainline > \ / > F1-----F2------F3 Feature_A > > And then you could easily use rebase to get the job done. But on the other hand the intermediate merges from the Mainline make for much simpler merges, right?. If merging is done only when Feature_A is ready it might become a real pain. It might take several month to complete it and the mainline might have changed a lot. > > Had you known beforehand that Feature_A is a candidate for backporting, > you would have even branch from an older commit like this: > > o--o--o Release_1.0 > / \ \ > o-o-o--o--o-o-o-o-o-o---o--o Mainline > \ / > F1--------F2-------F3 Feature_A > > > Then you could easily merge Feature_A to Release_1.0 as well, without > merging anything unrelated. > > But that's just for the future... > Yes, sure. If I would know the future already today I would not need to do any coding anymore :-) But seriously our policy is clear: Bugfixes (and small enhancements) go to the release branch to end up in the next minor release. The release branch gets merged with the mainline so that it is always a superset. Big new features are developed in seperated branches and are finaly merged to the mainline to end up in the next major release. But every now and then the managment is so excited about such a new feature that they want it in the next minor release. That's life. > > Given you current history, you could use format-patch + am like this: > > git format-patch --stdout --first-parent Mainline..Feature_A > fa.mbox > git checkout Release_1.0 > git am -3 fa.mbox > > The --first-parent options make it follow the first parent of the merge > commits only, so the whole stuff on the Mainline branch is ignored. And > you just get F1, F2 and F3 in fa.mbox, which you then apply using am. > Ah, great! I played with format-patch + am but missed the '--first-parent' option. I will give it a try. Thanks a lot! > > A long time ago, I hacked the --first-parent thing into rebase, but (of > course) the first iteration of the patch wasn't quite perfect and as > I've not been scratching my own itch there, I never got around to > actually polish the patch so it could get into git.git. Maybe you want > to pick it up? > > http://thread.gmane.org/gmane.comp.version-control.git/62782 In case we go for git this might very well be the case. > > Björn Peter -- 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