Fwd: What is the best way to backport a feature?

[Peter Weseloh <peter.weseloh@googlemail.com>]

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