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. That's
how we do such things where I work (although not with the
kernel), and it's working wonderfully (we had that multi-
conflict problem earlier too). Note that this will cause
you to either get a new branch-name for your release-
branch, or your current release-branch to get rebuilt.
Neither is actually horrible in this case, since you could
easily justify taking a flag-day when doing a kernel upgrade.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
--
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
