Re: How to merge from newer branch to older branches?

[Jeff King <peff@peff.net>]

On Tue, Apr 21, 2009 at 12:24:26PM -0700, skillzero@gmail.com wrote:

> We have a "future" branch for new development. I wanted to add a new
> feature so I branched from "future" to create a branch named
> "feature". I completed the work, but now they've decided they need
> that on two older branches. It looks like this:
> [...]
> I've read I should have started from the oldest common denominator
> branch that I might ever want, but at the time I created the branch,

Right. Junio branches all topics in git from "master", but then merges
promising ones into "next". When the topic is ready for master, he can
then just merge the topic branch, pulling in that topic but not the rest
of next.

> "future" was it because we thought 1.1 and 1.2 were locked down and
> not going to add new features. But things change and I need to roll my
> feature into 1.1 and 1.2.

Yep. Advanced planning is not always possible. :)

> What's the best way to merge changes on the "feature" branch into the
> 1.1 and 1.2 branches? If I try to checkout 1.1 then 'git merge

If it is just one or two commits, you probably just want to "git
cherry-pick" them onto your older branches.

If it is a larger series, or one which might see more development, you
might want to use "git rebase" to rewrite the branch as if it were based
on 1.1, and then merge that into 1.1, 1.2, and feature.

> feature', it (obviously) merges in a bunch of changes from "future"
> that I don't want (and has a bunch of conflicts). I also tried just
> cherry-picking commits a, b, and c from the "feature" branch. That
> mostly worked, but there were some surprising conflicts. Text that had
> been inserted into a couple files (which had been untouched in 1.1 and
> 1.2) caused a conflict when it seemed like it should have just added
> the lines without conflict. I realize it's difficult to know why it
> conflicted without seeing the changes, but I'm just asking in a more
> general way how I should be doing merges like this.

Yes, without seeing the conflicts it's hard to say. But presumably the
added lines provide context, so git was having a hard time trying to
figure out where in the old file your changes would go (you can think of
cherry-pick as the moral equivalent of "git show $COMMIT | git apply";
so you are basically applying a patch on top of something that it is
not quite the same).

If you are having trouble resolving conflicts, you might try using "git
mergetool" to fire up an external resolver that may provide a richer
interface (I use xxdiff with mergetool, myself).

> Is cherry-picking the best way? It seems pretty tedious because I have
> to do each commit in reverse order (although I could script it). I was
> hoping there was a way to say "apply all the changes from when
> "feature" branched up to its tip". I would also like to preserve the
> commit history rather than just making making one big commit of all
> the changes.

In its simplest form, rebase is basically cherry-picking a series of
commits. So that would make things a bit less tedious for you, but you
will probably still end up with the same set of conflicts.

-Peff