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

[Ping Yin <pkufranky@gmail.com>]

On Mon, Mar 30, 2009 at 5:33 PM, Andreas Ericsson <ae@op5.se> wrote:
> Brian Foster wrote:
>>
>>  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.

Or just (say, always use rebase instead of merge)

git rebase -i 2.6.26.8 --onto 2.6.27