On Mon, Mar 30, 2009 at 5:33 PM, Andreas Ericsson <ae@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
