From: Ping Yin Date: Mon, 30 Mar 2009 15:20:00 GMT Subject: Re: [Q] merging from one (kernel) stable to another? Message-ID: <46dff0320903300820u3efb26c2x5658afc71096d180@mail.gmail.com> In-Reply-To: <49D09207.9080407@op5.se> On Mon, Mar 30, 2009 at 5:33 PM, Andreas Ericsson 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