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

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Nov 29, 2009, 18:17 UTC
Message-ID: <20091129181758.GA9533@atjola.homenet>
In-Reply-To: <4db3b0200911290941j42c5a0aaq2c6a9836b38066b2@mail.gmail.com>

On 2009.11.29 18:41:35 +0100, Peter Weseloh wrote:

Show 14 quoted lines

> >  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.

That's usually more often true with CVS or SVN than with git, but ...

> It might take several month to complete it and the mainline might have
> changed a lot.

... over such a long timeframe, yes, things might become ugly. OTOH such a long timeframe might also mean that the topic branch actually does too much. Splitting such a large thing into more manageable pieces would help there, as you could merge completed topic branch to your mainline branch earlier and more often.

Show 16 quoted lines

> > 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 :-)

I meant something like "I just said that, so you can avoid problems in the future" ;-) But yeah, knowing beforehand that things should go into a maintenance branch isn't common, unless it's about a bugfix.

Show 13 quoted lines

> > 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!

Well, it's a rev-list option, which might work by accident. Junio recently said that the fact that format-patch accepts path limiting is by accident, might be true for --first-parent as well... No clue. Junio?

Björn