Re: [Q] merging from one (kernel) stable to another?
- From
Kris Shannon <kris@shannon.id.au>
- Date
- Mar 31, 2009, 04:20 UTC
- Message-ID
- <e51f4f550903302120s62f6056bg95f7a5aca4ec3d@mail.gmail.com>
- In-Reply-To
- <49D09207.9080407@op5.se>
2009/3/30 Andreas Ericsson <ae@op5.se>
Show 6 quoted lines
> > Brian Foster wrote: >> >> Whilst this question involves linux(-mips) kernel tree, >> it's a git(-related?) question, not a kernel question .... >>
...
Show 13 quoted lines
>> 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.
git mailing list <git@vger.kernel.org>
What you could do is something like:
git checkout -b mystable-27 linux-2.6.27-stable git merge -s ours linux-2.6.26-stable git checkout local-changes-26 git merge mystable-27
The extra merge might allow git to distinguish between 26->27 conflicts and conflicts due to your local-changes.
BTW, when doing these merges between release branches you probably want to increase merge.renamelimit.