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

[Jeff King <peff@peff.net>]

On Wed, Apr 22, 2009 at 02:01:01PM -0700, skillzero@gmail.com wrote:

> I'm not sure I understand. When I did the original rebase of "feature"
> onto the merge-base of all the branches I wanted to merge to (v1.1 and
> v1.2 in this case), the end result was that "feature" is now based on

Err, sorry, I was confusing your "future" branch and your "feature"
branch. Wherever I said "feature", I meant "future", and "topic" I meant
"feature". Yikes.

So you would make bug-fixes on "feature", and then just re-merge it to
1.1, 1.2, and future.

> the merge-base. When I merged "feature" into 1.1, I had to fix some
> conflicts so in the log I see my conflict fix commit then a merge
> commit, but "feature" wasn't changed (only v1.1 was).

Right. So now the merge-base between feature and 1.1 is the new merge
commit. And when you re-merge them, you will only look at things that
happened on the feature branch since that merge-base.

> I was thinking that if I find a bug in my original "feature" branch, I
> would commit the fix to the "feature" branch then merge that into
> v1.1, v1.2, master, etc. But I was thinking that when I tried to merge
> "feature" into v1.1 (which previously needed a commit to fix
> conflicts), I'd need to re-fix those same conflicts.

Nope, because the merge commit already records the state of the tree
once those conflicts are fixed. Now it's possible that the _bugfix_ may
have its own conflicts. But you shouldn't see the same conflicts again.

> When I look at the log for v1.1 though, maybe I just misunderstood the
> way the conflicts are resolved in git? I was thinking the conflicting
> merge would end up as one big commit that's a combination of the
> "feature"'s commits and my conflict fixes.

Sort of.  It is a new commit with two parents: the previous tip of v1.1,
and the tip of "feature". But its tree contains the state with all of
v1.1, all of feature's commits, and your fixes.

-Peff