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

From: Andreas Ericsson <ae@op5.se>
Date: Mar 30, 2009, 09:33 UTC
Message-ID: <49D09207.9080407@op5.se>
In-Reply-To: <200903301024.08848.brian.foster@innova-card.com>

Brian Foster wrote:

Show 27 quoted lines

>   Whilst this question involves linux(-mips) kernel tree,
>  it's a git(-related?) question, not a kernel question ....
> 
>   We are currently in the process of upgrading our embedded
>  system from kernel 2.6.21(-ish) to at least 2.6.26.8;  and
>  later, at some time in the future on to 2.6.3x or something.
>  Going from 2.6.21 to .22 to .23 and so on to .26, then to
>  .26.1 and so on to .26.8 is “easy” in the sense there are
>  very few conflicts with our existing baseline (e.g., just
>  2 or 3 in 2 or 3 files).
> 
>   .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master
>      \              \       \           \      \
>      .21-stable  .22-stable .23-stable   \     .27-stable
>                                         .26.8
>                                            \
>                                            .26-stable
> 
>   But (using 2.6.21-stable and 2.6.22-stable as proxies),
>  tests indicate that going from .26.8 to .27 or anything
>  later will have numerous conflicts (100s? in more than
>  30 files).  Thinking about it, this isn't too surprising
>  since the -stable branches cherry-pick important/benign
>  fixes from later revisions.
> 
>   What's frustrating is that in essentially all “conflict”
>  cases, the resolution is simple:  Use the later version.

The trouble is "essentially all", as opposed to "all". Git can never know which of the conflicts are which, so it will leave it all up to you.

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. That's how we do such things where I work (although not with the kernel), and it's working wonderfully (we had that multi- conflict problem earlier too). Note that this will cause you to either get a new branch-name for your release- branch, or your current release-branch to get rebuilt.

Neither is actually horrible in this case, since you could easily justify taking a flag-day when doing a kernel upgrade.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.