From: Andreas Ericsson <ae@op5.se>
To: Brian Foster <brian.foster@innova-card.com>
Cc: git mailing list <git@vger.kernel.org>
Subject: Re: [Q] merging from one (kernel) stable to another?
Date: Mon, 30 Mar 2009 11:33:59 +0200 [thread overview]
Message-ID: <49D09207.9080407@op5.se> (raw)
In-Reply-To: <200903301024.08848.brian.foster@innova-card.com>
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@op5.se
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.
next prev parent reply other threads:[~2009-03-30 9:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-30 8:24 [Q] merging from one (kernel) stable to another? Brian Foster
2009-03-30 9:33 ` Andreas Ericsson [this message]
2009-03-30 10:38 ` Johannes Sixt
2009-03-30 11:58 ` Brian Foster
2009-03-30 12:19 ` Johannes Sixt
2009-03-30 12:40 ` Brian Foster
2009-03-30 12:19 ` Andreas Ericsson
2009-03-30 12:51 ` Brian Foster
2009-03-30 13:52 ` Andreas Ericsson
2009-03-30 15:20 ` Ping Yin
2009-03-31 4:20 ` Kris Shannon
2009-03-30 17:31 ` Daniel Barkalow
2009-03-31 7:30 ` Brian Foster
2009-03-30 18:23 ` Uwe Kleine-König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49D09207.9080407@op5.se \
--to=ae@op5.se \
--cc=brian.foster@innova-card.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).