On Mon, 30 Mar 2009, 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. Why are you going from .26.8 to .27? Based on the -stable policy, there should be no reason not to skip .26.x between .26 and .27. In fact, it's not unlikely that merging both .26.8 and .27 will introduce bugs when the same issue was fixed in different places in the two branches: a narrow patch to paper over the identified problem in -stable and an intrusive patch to change some API to make simpler code correct in the mainline. That is, the correct way of merging changes from -stable with the latest mainline series is always to take the mainline version, even if the -stable changes don't conflict at all. It should actually be ideal to just merge your local changes directly with the mainline kernel you want to end up using. But you might want to merge first with earlier mainline kernels in order to get fewer or easier conflicts per step. -Daniel *This .sig left intentionally blank*
