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.
Very few conflicts are caused by our local changes. But
the merge tool I used (‘tkdiff’ via ‘git mergetool’) for
my tests doesn't seem to make that resolution an easy
thing to do — I (seem to) have to manually check each
and every conflict, which very quickly becomes tedious
(read: error-prone).
Is there a (relatively) easy way to manage this situation?
Trying some internet searches didn't find much of anything,
albeit just what to search for isn't too clear.
Thanks for any suggestions (including “RFT<a named>M”).
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
--
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
