Re: [Q] merging from one (kernel) stable to another?
On Mon, Mar 30, 2009 at 5:33 PM, Andreas Ericsson <ae@op5.se> wrote:
Show 37 quoted lines
> 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
Ping Yin <pkufranky@gmail.com>