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

From: skillzero@gmail.com <skillzero@gmail.com>
Date: Apr 22, 2009, 21:01 UTC
Message-ID: <2729632a0904221401u43af69a5ncec0f3f274ad648f@mail.gmail.com>
In-Reply-To: <20090422201541.GC14146@coredump.intra.peff.net>

On Wed, Apr 22, 2009 at 1:15 PM, Jeff King <peff@peff.net> wrote:

Show 13 quoted lines

>
> On Wed, Apr 22, 2009 at 10:44:06AM -0700, skillzero@gmail.com wrote:
>
>> It seems like this merge conflict is going to cause problems if I try
>> to re-merge to pick up a bug fix to 'feature' in the future. Looking
>> at the documentation, it sounds like 'git rerere' can help by
>> re-applying the manual conflict resolution I did?
>
> It shouldn't. Remember that your merges into 1.1, 1.2, etc, created a
> new merge base. So when you have bug fixes to make to this topic, you
> don't put them on the "feature" branch, but onto this topic branch. Then
> you re-merge the topic branch into 1.1., 1.2, feature, etc, and it will
> look only at the new bugfix.

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

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.

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.

But in the log for v1.1, it looks like my conflict fixing commit may have just "fixed" the v1.1 branch such that it could accept a "feature" merge without conflict. If that's true then a future merge of "feature" containing new commits should just merge without conflict. That would be awesome if that's the way conflicting resolving in git works.

Show 11 quoted lines

> However, the first entry in the reflog for that branch ref should
> indicate branch creation (unless it is so old that it has expired).
> Something like:
>
>  $ git branch foo origin/master
>  $ git reflog show foo
>  0be9bc0 foo@{0}: branch: Created from origin/master
>
> So 0be9bc0 would be the creation point in this case. But you might have
> totally rewritten the branch after that point, so 0be9bc0 might not be a
> useful value anymore.

Thanks, that shows what I need. For my case, it happened to be @{58}. Is there a way to reverse the order or a special syntax to say "0 from the end"? Trying --reverse said "cannot combine --reverse with --walk-reflogs" and trying @{-1} show me something else.