threads / discuss / 18634

[Q] merging from one (kernel) stable to another?

Subject: [Q] merging from one (kernel) stable to another?

## tl;dr

14 messages between Mar 30, 2009 and Mar 31, 2009.

replies: 13people: 7as markdown or json

Brian Foster· Mar 30, 2009, 08:24 UTC · lore
  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
Andreas Ericsson· Mar 30, 2009, 09:33 UTC · re: Brian Foster · lore

Re: [Q] merging from one (kernel) stable to another?

Brian Foster wrote:
Show 27 quoted lines
>   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.
Johannes Sixt· Mar 30, 2009, 10:38 UTC · re: Andreas Ericsson · lore

Re: [Q] merging from one (kernel) stable to another?

Andreas Ericsson schrieb:
> 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.

After you have successfully done *that*, you know how the resulting tree must look like, and you give it a tag, say "like-this". If you really want to have a merge, then you can just repeat the merge with your original branch, at which time you will get tons of conflicts. Now you just 'git checkout like-this -- .' and you have all your conflicts resolved in the way you need them.

-- Hannes
Brian Foster· Mar 30, 2009, 11:58 UTC · re: Johannes Sixt · lore

Re: [Q] merging from one (kernel) stable to another?

On Monday 30 March 2009 12:38:43 Johannes Sixt wrote:
> Andreas Ericsson schrieb:
> > 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.
[ I'm going from .21 to .26.8, so I think you've got that reversed? ]
Show 7 quoted lines
> 
> After you have successfully done *that*, you know how the resulting
> tree must look like, and you give it a tag, say "like-this".
> If you really want to have a merge, then you can just repeat the
> merge with your original branch, at which time you will get tons
> of conflicts.  Now you just 'git checkout like-this -- .' and you
> have all your conflicts resolved in the way you need them.
Andreas & Hannes,
  Thanks for the suggestion.  I'll have to experiment,
 but off-the-top-of-my-head, I think I do want a merge,
 so that it's easier to track the history of individual
 local changes.  Having said that, I'm not entirely sure
 I follow your suggestions.  What I think you mean is:
  (1)  Create a patch which is all (local) changes
         (née diffs) from linux-mips.21 to our.21;
  (2)  Checkout linux-mips.26.8 (e.g.);
  (3)  Apply the patch created in (1), above;
  (4)  Tag the result `like-this';
  (5)  Checkout our.21;  and
  (6)  Merge with `like-this'.
 I admit that now that I write the steps out, it seems
 to make sense ....?   Am I understanding correctly?
  Thanks for the suggestions.  Other suggestions are also
 quite welcome.
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
Johannes Sixt· Mar 30, 2009, 12:19 UTC · re: Brian Foster · lore

Re: [Q] merging from one (kernel) stable to another?

Brian Foster schrieb:
Show 25 quoted lines
> On Monday 30 March 2009 12:38:43 Johannes Sixt wrote:
>> Andreas Ericsson schrieb:
>>> 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.
> [ I'm going from .21 to .26.8, so I think you've got that reversed? ]
>> After you have successfully done *that*, you know how the resulting
>> tree must look like, and you give it a tag, say "like-this".
>> If you really want to have a merge, then you can just repeat the
>> merge with your original branch, at which time you will get tons
>> of conflicts.  Now you just 'git checkout like-this -- .' and you
>> have all your conflicts resolved in the way you need them.
> 
> Andreas & Hannes,
> 
>   Thanks for the suggestion.  I'll have to experiment,
>  but off-the-top-of-my-head, I think I do want a merge,
>  so that it's easier to track the history of individual
>  local changes.  Having said that, I'm not entirely sure
>  I follow your suggestions.  What I think you mean is:
> 
>   (1)  Create a patch which is all (local) changes
>          (née diffs) from linux-mips.21 to our.21;
>   (2)  Checkout linux-mips.26.8 (e.g.);
>   (3)  Apply the patch created in (1), above;

format-patch creates a patch series. You apply the whole series, e.g. with 'git am'. But for this workflow you could also just create a single patch and apply it to linux-mips.26.8, just as you wrote.

The important point is that you forge this tree into the shape that you finally want to have in the merge (that you will make later). At this point you only have to deal with conflicts and regressions that arise from your own changes, which makes your life much easier than if you also had to deal with conflicts that are outside your own changes.

>   (4)  Tag the result `like-this';
>   (5)  Checkout our.21;  and
>   (6)  Merge with `like-this'.

No, you merge with linux-mips.26.8. This will again give you a lot of conflicts. But you do

   (7) git checkout like-this -- .

that is, you overwrite the merge result (that has conflicts) with your known-good tree called "like-this". This resolves all conflicts in the way that you wanted them.

-- Hannes
Brian Foster· Mar 30, 2009, 12:40 UTC · re: Johannes Sixt · lore

Re: [Q] merging from one (kernel) stable to another?

On Monday 30 March 2009 14:19:08 Johannes Sixt wrote:
Show 16 quoted lines
> Brian Foster schrieb:
>[ ... ]
> >   Thanks for the suggestion.  I'll have to experiment,
> >  but off-the-top-of-my-head, I think I do want a merge,
> >  so that it's easier to track the history of individual
> >  local changes.  Having said that, I'm not entirely sure
> >  I follow your suggestions.  What I think you mean is:
> > 
> >   (1)  Create a patch which is all (local) changes
> >          (née diffs) from linux-mips.21 to our.21;
> >   (2)  Checkout linux-mips.26.8 (e.g.);
> >   (3)  Apply the patch created in (1), above;
> 
> format-patch creates a patch series.  You apply the whole series,
> e.g. with 'git am'. But for this workflow you could also just create
> a single patch and apply it to linux-mips.26.8, just as you wrote.
  Point taken.  I was being a bit sloppy there; I well know
 `git format-patch' (which we use in our internal workflow)
 generates a patch series, and that `git am' applies them.
 Apologies for the confusion.  Sorry!
Show 6 quoted lines
> The important point is that you forge this tree into the shape that
> you finally want to have in the merge (that you will make later).
> At this point you only have to deal with conflicts and regressions
> that arise from your own changes, which makes your life much easier
> than if you also had to deal with conflicts that are outside your
> own changes.
  Gottcha.  Thanks for clarifying.
Show 12 quoted lines
> >   (4)  Tag the result `like-this';
> >   (5)  Checkout our.21;  and
> >   (6)  Merge with `like-this'.
> 
> No, you merge with linux-mips.26.8. This will again give you a lot
> of conflicts. But you do
> 
>    (7) git checkout like-this -- .
> 
> that is, you overwrite the merge result (that has conflicts) with
> your known-good tree called "like-this". This resolves all conflicts
> in the way that you wanted them.
  Ah!  Neat.  I think I get it (er, git it?) now ....
 Many thanks for your patient and very helpful replies!
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
Andreas Ericsson· Mar 30, 2009, 12:19 UTC · re: Brian Foster · lore

Re: [Q] merging from one (kernel) stable to another?

Brian Foster wrote:
Show 23 quoted lines
> On Monday 30 March 2009 12:38:43 Johannes Sixt wrote:
>> Andreas Ericsson schrieb:
>>> 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.
> [ I'm going from .21 to .26.8, so I think you've got that reversed? ]
>> After you have successfully done *that*, you know how the resulting
>> tree must look like, and you give it a tag, say "like-this".
>> If you really want to have a merge, then you can just repeat the
>> merge with your original branch, at which time you will get tons
>> of conflicts.  Now you just 'git checkout like-this -- .' and you
>> have all your conflicts resolved in the way you need them.
> 
> Andreas & Hannes,
> 
>   Thanks for the suggestion.  I'll have to experiment,
>  but off-the-top-of-my-head, I think I do want a merge,
>  so that it's easier to track the history of individual
>  local changes.  Having said that, I'm not entirely sure
>  I follow your suggestions.  What I think you mean is:
> 
>   (1)  Create a patch which is all (local) changes
>          (née diffs) from linux-mips.21 to our.21;

This is wrong. Create several git-patches, each containing the equivalence of one commit (complete with diff, author info and commit message).

>   (2)  Checkout linux-mips.26.8 (e.g.);
>   (3)  Apply the patch created in (1), above;

Except it'll be "apply the patches, re-creating history as if it had been done with a different base from the start".

>   (4)  Tag the result `like-this';
>   (5)  Checkout our.21;  and
>   (6)  Merge with `like-this'.
> 
Merge is not necessary.
>  I admit that now that I write the steps out, it seems
>  to make sense ....?   Am I understanding correctly?
>

Almost. "git help format-patch" and "git help am" will get you the rest of the way, I think.

-- 
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.
Brian Foster· Mar 30, 2009, 12:51 UTC · re: Andreas Ericsson · lore

Re: [Q] merging from one (kernel) stable to another?

On Monday 30 March 2009 14:19:11 Andreas Ericsson wrote:
Show 8 quoted lines
> Brian Foster wrote:
> >[ ... ]
> >   (1)  Create a patch which is all (local) changes
> >          (née diffs) from linux-mips.21 to our.21;
> 
> This is wrong.  Create several git-patches, each containing
> the equivalence of one commit (complete with diff, author
> info and commit message).
  Yes, I was being sloppy there.  Internally, we use both
 `git format-patch' and `git am', but have a bad(?) habit
 of referring to a patch series as “a patch”.  Apologies
 for the confusion.  Sorry!
Show 6 quoted lines
> >   (2)  Checkout linux-mips.26.8 (e.g.);
> >   (3)  Apply the patch created in (1), above;
> 
> Except it'll be "apply the patches, re-creating history
> as if it had been done with a different base from the
> start".
  Yes.
Show 5 quoted lines
> >   (4)  Tag the result `like-this';
> >   (5)  Checkout our.21;  and
> >   (6)  Merge with `like-this'.
> 
> Merge is not necessary.
  <Shrugs/>  I'll going to try in both ways (with and without
 merging) to better understand just what the results are like.
Show 5 quoted lines
> >  I admit that now that I write the steps out, it seems
> >  to make sense ....?   Am I understanding correctly?
> 
> Almost. "git help format-patch" and "git help am" will get
> you the rest of the way, I think.
  ;-)   Well, I did say “RTF<a named>M” is useful....!
  Many thanks for your patient and very helpful replies.
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
Andreas Ericsson· Mar 30, 2009, 13:52 UTC · re: Brian Foster · lore

Re: [Q] merging from one (kernel) stable to another?

Brian Foster wrote:
Show 10 quoted lines
> On Monday 30 March 2009 14:19:11 Andreas Ericsson wrote:
>> Brian Foster wrote:
> 
>>>   (4)  Tag the result `like-this';
>>>   (5)  Checkout our.21;  and
>>>   (6)  Merge with `like-this'.
>> Merge is not necessary.
> 
>   <Shrugs/>  I'll going to try in both ways (with and without
>  merging) to better understand just what the results are like.

If you get the tree into the state you want and simply want to connect the histories, you can do

  git merge -s ours $other_branch

which will record the tree from the current commit as the tree for the merge-commit (ie, all changes from $other_branch are thrown away, and the merge always succeeds without conflicts).

-- 
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.
Ping Yin· Mar 30, 2009, 15:20 UTC · re: Andreas Ericsson · lore

Re: [Q] merging from one (kernel) stable to another?

On Mon, Mar 30, 2009 at 5:33 PM, Andreas Ericsson <ae@op5.se> wrote:
Show 37 quoted lines
> 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.
Or just (say, always use rebase instead of merge)
git rebase -i 2.6.26.8 --onto 2.6.27
Kris Shannon· Mar 31, 2009, 04:20 UTC · re: Andreas Ericsson · lore

Re: [Q] merging from one (kernel) stable to another?

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.

Daniel Barkalow· Mar 30, 2009, 17:31 UTC · re: Brian Foster · lore

Re: [Q] merging from one (kernel) stable to another?

On Mon, 30 Mar 2009, Brian Foster wrote:
Show 24 quoted lines
>   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*
Brian Foster· Mar 31, 2009, 07:30 UTC · re: Daniel Barkalow · lore

Re: [Q] merging from one (kernel) stable to another?

On Monday 30 March 2009 19:31:18 Daniel Barkalow wrote:
Show 28 quoted lines
> 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.
Daniel,
  That's a good question!  The policy to-date has been to
 ignore the -stable branches entirely, and go from release
 to release; i.e., .21 to .22 to ... to .26 to .27 et al.
 We (deliberately!) stay several releases behind (being
 bang-up-to-date isn't too important to our market/product,
 but having a robust secure system is extremely important).
  The current feeling is we should probably be moving from
 -stable to -stable, i.e., .21-stable to .22-stable to ...
 to .26-stable and later to .27-stable and so on.  This is
 based, in part, on observing the changes that are in -stable
 and realizing some of them are highly desirable.  This new
 idea/plan of going from -stable to -stable can change if
 there's a good reason.  It's currently in a state of flux.
  So I somewhat incorrectly described the thinking, mixing
 up our historical practice with the proposed new policy.
 In my defense, my I point out that we are particularly
 interested in some MIPS changes on .26-stable, and, at the
 the moment, have decided to not go to .27 for this cycle.
 (Admittedly, with the release of .29, the decision not to
 go to .27 has been challenged, but the issue hasn't been
 looked into in any detail (yet? as far as I know).)
  Anyways, good catch!  I take your point.  Many thanks.
Show 9 quoted lines
>                                                            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.
  Yep!  We don't want to merge changes from -stable
 into master (mainline).  That was a mistake in my
 description.  Again, thanks for pointing it out.
> 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.
  Indeed.  We are progressing one release at a time.
 (I've been insisting on this!)  However, given we're
 not targeting .27 or later at this cycle, and that
 we know there are changes on .26-stable we want/need,
 it's (almost) a dead cert our next release will be
 based on some point in .26-stable (I'm using .26.8
 as a proxy as it's the latest (when I checked) tag
 on .26-stable).
  Things are in flux, and suggestions are certainly
 welcome.  Thanks for your very helpful observations.
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
Uwe Kleine-König· Mar 30, 2009, 18:23 UTC · re: Brian Foster · lore

Re: [Q] merging from one (kernel) stable to another?

On Mon, Mar 30, 2009 at 10:24:08AM +0200, Brian Foster wrote:
Show 24 quoted lines
>   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.

Assuming you have your master on top of .21-stable and want to go to .26-stable, the following might work better for you:

	$ git checkout -b mydot26stable .26-stable
	$ git merge -s ours .21-stable
	$ git checkout master
	$ git merge mydot26stable	
Note this is not tested, just came to my mind...

Best regards Uwe

-- 
Pengutronix e.K.                              | Uwe Kleine-König            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |

← back to recent threads