Re: [Q] merging from one (kernel) stable to another?

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Mar 30, 2009, 12:19 UTC
Message-ID: <49D0B8BC.2010405@viscovery.net>
In-Reply-To: <200903301358.48864.brian.foster@innova-card.com>

Brian Foster schrieb:

Show 25 quoted lines

> On Monday 30 March 2009 12:38:43 Johannes Sixt wrote:
>> Andreas Ericsson schrieb:
>>> A possibly better approach for you is to "git format-patch"
>>> your own changes and apply them to a clean 2.6.26.8 tree
>>> instead of trying to merge 2.6.26.8 into 2.6.21.
> [ I'm going from .21 to .26.8, so I think you've got that reversed? ]
>> After you have successfully done *that*, you know how the resulting
>> tree must look like, and you give it a tag, say "like-this".
>> If you really want to have a merge, then you can just repeat the
>> merge with your original branch, at which time you will get tons
>> of conflicts.  Now you just 'git checkout like-this -- .' and you
>> have all your conflicts resolved in the way you need them.
> 
> Andreas & Hannes,
> 
>   Thanks for the suggestion.  I'll have to experiment,
>  but off-the-top-of-my-head, I think I do want a merge,
>  so that it's easier to track the history of individual
>  local changes.  Having said that, I'm not entirely sure
>  I follow your suggestions.  What I think you mean is:
> 
>   (1)  Create a patch which is all (local) changes
>          (née diffs) from linux-mips.21 to our.21;
>   (2)  Checkout linux-mips.26.8 (e.g.);
>   (3)  Apply the patch created in (1), above;

format-patch creates a patch series. You apply the whole series, e.g. with 'git am'. But for this workflow you could also just create a single patch and apply it to linux-mips.26.8, just as you wrote.

The important point is that you forge this tree into the shape that you finally want to have in the merge (that you will make later). At this point you only have to deal with conflicts and regressions that arise from your own changes, which makes your life much easier than if you also had to deal with conflicts that are outside your own changes.

>   (4)  Tag the result `like-this';
>   (5)  Checkout our.21;  and
>   (6)  Merge with `like-this'.

No, you merge with linux-mips.26.8. This will again give you a lot of conflicts. But you do

   (7) git checkout like-this -- .

that is, you overwrite the merge result (that has conflicts) with your known-good tree called "like-this". This resolves all conflicts in the way that you wanted them.

-- Hannes