{"thread":{"id":"18634","subject":"[Q] merging from one (kernel) stable to another?","startedAt":"2009-03-30T08:24:08Z","lastAt":"2009-03-31T07:30:34Z","messageCount":14,"participants":["Brian Foster","Andreas Ericsson","Johannes Sixt","Ping Yin","Daniel Barkalow","Uwe Kleine-König","Kris Shannon"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"109855","messageId":"200903301024.08848.brian.foster@innova-card.com","threadId":"18634","inReplyTo":null,"subject":"[Q] merging from one (kernel) stable to another?","fromName":"Brian Foster","fromEmail":"brian.foster@innova-card.com","sentAt":"2009-03-30T08:24:08Z","receivedAt":"2009-03-30T08:24:08Z","isPatch":false,"sender":{"key":"brian.foster@innova-card.com","avatar":null},"body":" Whilst this question involves linux(-mips) kernel tree,\n it's a git(-related?) question, not a kernel question ....\n\n We are currently in the process of upgrading our embedded\n system from kernel 2.6.21(-ish) to at least 2.6.26.8; and\n later, at some time in the future on to 2.6.3x or something.\n Going from 2.6.21 to .22 to .23 and so on to .26, then to\n .26.1 and so on to .26.8 is “easy” in the sense there are\n very few conflicts with our existing baseline (e.g., just\n 2 or 3 in 2 or 3 files).\n\n .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master\n \\ \\ \\ \\ \\\n .21-stable .22-stable .23-stable \\ .27-stable\n .26.8\n \\\n .26-stable\n\n But (using 2.6.21-stable and 2.6.22-stable as proxies),\n tests indicate that going from .26.8 to .27 or anything\n later will have numerous conflicts (100s? in more than\n 30 files). Thinking about it, this isn't too surprising\n since the -stable branches cherry-pick important/benign\n fixes from later revisions.\n\n What's frustrating is that in essentially all “conflict”\n cases, the resolution is simple: Use the later version.\n Very few conflicts are caused by our local changes. But\n the merge tool I used (‘tkdiff’ via ‘git mergetool’) for\n my tests doesn't seem to make that resolution an easy\n thing to do — I (seem to) have to manually check each\n and every conflict, which very quickly becomes tedious\n (read: error-prone).\n\n Is there a (relatively) easy way to manage this situation?\n Trying some internet searches didn't find much of anything,\n albeit just what to search for isn't too clear.\n\n Thanks for any suggestions (including “RFTM”).\ncheers!\n\t-blf-\n\n-- \n“How many surrealists does it take to | Brian Foster\n change a lightbulb? Three. One calms | somewhere in south of France\n the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!\n with brightly-coloured machine tools.” | http://www.stopesso.com\n"},{"id":"109869","messageId":"49D09207.9080407@op5.se","threadId":"18634","inReplyTo":"200903301024.08848.brian.foster@innova-card.com","subject":"Re: [Q] merging from one (kernel) stable to another?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-03-30T09:33:59Z","receivedAt":"2009-03-30T09:33:59Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Brian Foster wrote:\n> Whilst this question involves linux(-mips) kernel tree,\n> it's a git(-related?) question, not a kernel question ....\n> \n> We are currently in the process of upgrading our embedded\n> system from kernel 2.6.21(-ish) to at least 2.6.26.8; and\n> later, at some time in the future on to 2.6.3x or something.\n> Going from 2.6.21 to .22 to .23 and so on to .26, then to\n> .26.1 and so on to .26.8 is “easy” in the sense there are\n> very few conflicts with our existing baseline (e.g., just\n> 2 or 3 in 2 or 3 files).\n> \n> .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master\n> \\ \\ \\ \\ \\\n> .21-stable .22-stable .23-stable \\ .27-stable\n> .26.8\n> \\\n> .26-stable\n> \n> But (using 2.6.21-stable and 2.6.22-stable as proxies),\n> tests indicate that going from .26.8 to .27 or anything\n> later will have numerous conflicts (100s? in more than\n> 30 files). Thinking about it, this isn't too surprising\n> since the -stable branches cherry-pick important/benign\n> fixes from later revisions.\n> \n> What's frustrating is that in essentially all “conflict”\n> cases, the resolution is simple: Use the later version.\n\nThe trouble is \"essentially all\", as opposed to \"all\". Git\ncan never know which of the conflicts are which, so it will\nleave it all up to you.\n\nA possibly better approach for you is to \"git format-patch\"\nyour own changes and apply them to a clean 2.6.26.8 tree\ninstead of trying to merge 2.6.26.8 into 2.6.21. That's\nhow we do such things where I work (although not with the\nkernel), and it's working wonderfully (we had that multi-\nconflict problem earlier too). Note that this will cause\nyou to either get a new branch-name for your release-\nbranch, or your current release-branch to get rebuilt.\n\nNeither is actually horrible in this case, since you could\neasily justify taking a flag-day when doing a kernel upgrade.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"109883","messageId":"49D0A133.80503@viscovery.net","threadId":"18634","inReplyTo":"49D09207.9080407@op5.se","subject":"Re: [Q] merging from one (kernel) stable to another?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-03-30T10:38:43Z","receivedAt":"2009-03-30T10:38:43Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Andreas Ericsson schrieb:\n> A possibly better approach for you is to \"git format-patch\"\n> your own changes and apply them to a clean 2.6.26.8 tree\n> instead of trying to merge 2.6.26.8 into 2.6.21.\n\nAfter you have successfully done *that*, you know how the resulting tree\nmust look like, and you give it a tag, say \"like-this\". If you really want\nto have a merge, then you can just repeat the merge with your original\nbranch, at which time you will get tons of conflicts. Now you just 'git\ncheckout like-this -- .' and you have all your conflicts resolved in the\nway you need them.\n\n-- Hannes\n"},{"id":"109891","messageId":"200903301358.48864.brian.foster@innova-card.com","threadId":"18634","inReplyTo":"49D0A133.80503@viscovery.net","subject":"Re: [Q] merging from one (kernel) stable to another?","fromName":"Brian Foster","fromEmail":"brian.foster@innova-card.com","sentAt":"2009-03-30T11:58:48Z","receivedAt":"2009-03-30T11:58:48Z","isPatch":false,"sender":{"key":"brian.foster@innova-card.com","avatar":null},"body":"On Monday 30 March 2009 12:38:43 Johannes Sixt wrote:\n> Andreas Ericsson schrieb:\n> > A possibly better approach for you is to \"git format-patch\"\n> > your own changes and apply them to a clean 2.6.26.8 tree\n> > instead of trying to merge 2.6.26.8 into 2.6.21.\n[ I'm going from .21 to .26.8, so I think you've got that reversed? ]\n> \n> After you have successfully done *that*, you know how the resulting\n> tree must look like, and you give it a tag, say \"like-this\".\n> If you really want to have a merge, then you can just repeat the\n> merge with your original branch, at which time you will get tons\n> of conflicts. Now you just 'git checkout like-this -- .' and you\n> have all your conflicts resolved in the way you need them.\n\nAndreas & Hannes,\n\n Thanks for the suggestion. I'll have to experiment,\n but off-the-top-of-my-head, I think I do want a merge,\n so that it's easier to track the history of individual\n local changes. Having said that, I'm not entirely sure\n I follow your suggestions. What I think you mean is:\n\n (1) Create a patch which is all (local) changes\n (née diffs) from linux-mips.21 to our.21;\n (2) Checkout linux-mips.26.8 (e.g.);\n (3) Apply the patch created in (1), above;\n (4) Tag the result `like-this';\n (5) Checkout our.21; and\n (6) Merge with `like-this'.\n\n I admit that now that I write the steps out, it seems\n to make sense ....? Am I understanding correctly?\n\n Thanks for the suggestions. Other suggestions are also\n quite welcome.\ncheers!\n\t-blf-\n\n-- \n“How many surrealists does it take to | Brian Foster\n change a lightbulb? Three. One calms | somewhere in south of France\n the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!\n with brightly-coloured machine tools.” | http://www.stopesso.com\n"},{"id":"109893","messageId":"49D0B8BC.2010405@viscovery.net","threadId":"18634","inReplyTo":"200903301358.48864.brian.foster@innova-card.com","subject":"Re: [Q] merging from one (kernel) stable to another?","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-03-30T12:19:08Z","receivedAt":"2009-03-30T12:19:08Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Brian Foster schrieb:\n> On Monday 30 March 2009 12:38:43 Johannes Sixt wrote:\n>> Andreas Ericsson schrieb:\n>>> A possibly better approach for you is to \"git format-patch\"\n>>> your own changes and apply them to a clean 2.6.26.8 tree\n>>> instead of trying to merge 2.6.26.8 into 2.6.21.\n> [ I'm going from .21 to .26.8, so I think you've got that reversed? ]\n>> After you have successfully done *that*, you know how the resulting\n>> tree must look like, and you give it a tag, say \"like-this\".\n>> If you really want to have a merge, then you can just repeat the\n>> merge with your original branch, at which time you will get tons\n>> of conflicts. Now you just 'git checkout like-this -- .' and you\n>> have all your conflicts resolved in the way you need them.\n> \n> Andreas & Hannes,\n> \n> Thanks for the suggestion. I'll have to experiment,\n> but off-the-top-of-my-head, I think I do want a merge,\n> so that it's easier to track the history of individual\n> local changes. Having said that, I'm not entirely sure\n> I follow your suggestions. What I think you mean is:\n> \n> (1) Create a patch which is all (local) changes\n> (née diffs) from linux-mips.21 to our.21;\n> (2) Checkout linux-mips.26.8 (e.g.);\n> (3) Apply the patch created in (1), above;\n\nformat-patch creates a patch series. You apply the whole series, e.g. with\n'git am'. But for this workflow you could also just create a single patch\nand apply it to linux-mips.26.8, just as you wrote.\n\nThe important point is that you forge this tree into the shape that you\nfinally want to have in the merge (that you will make later). At this\npoint you only have to deal with conflicts and regressions that arise from\nyour own changes, which makes your life much easier than if you also had\nto deal with conflicts that are outside your own changes.\n\n> (4) Tag the result `like-this';\n> (5) Checkout our.21; and\n> (6) Merge with `like-this'.\n\nNo, you merge with linux-mips.26.8. This will again give you a lot of\nconflicts. But you do\n\n (7) git checkout like-this -- .\n\nthat is, you overwrite the merge result (that has conflicts) with your\nknown-good tree called \"like-this\". This resolves all conflicts in the way\nthat you wanted them.\n\n-- Hannes\n"},{"id":"109892","messageId":"49D0B8BF.2000502@op5.se","threadId":"18634","inReplyTo":"200903301358.48864.brian.foster@innova-card.com","subject":"Re: [Q] merging from one (kernel) stable to another?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-03-30T12:19:11Z","receivedAt":"2009-03-30T12:19:11Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Brian Foster wrote:\n> On Monday 30 March 2009 12:38:43 Johannes Sixt wrote:\n>> Andreas Ericsson schrieb:\n>>> A possibly better approach for you is to \"git format-patch\"\n>>> your own changes and apply them to a clean 2.6.26.8 tree\n>>> instead of trying to merge 2.6.26.8 into 2.6.21.\n> [ I'm going from .21 to .26.8, so I think you've got that reversed? ]\n>> After you have successfully done *that*, you know how the resulting\n>> tree must look like, and you give it a tag, say \"like-this\".\n>> If you really want to have a merge, then you can just repeat the\n>> merge with your original branch, at which time you will get tons\n>> of conflicts. Now you just 'git checkout like-this -- .' and you\n>> have all your conflicts resolved in the way you need them.\n> \n> Andreas & Hannes,\n> \n> Thanks for the suggestion. I'll have to experiment,\n> but off-the-top-of-my-head, I think I do want a merge,\n> so that it's easier to track the history of individual\n> local changes. Having said that, I'm not entirely sure\n> I follow your suggestions. What I think you mean is:\n> \n> (1) Create a patch which is all (local) changes\n> (née diffs) from linux-mips.21 to our.21;\n\nThis is wrong. Create several git-patches, each containing\nthe equivalence of one commit (complete with diff, author\ninfo and commit message).\n\n> (2) Checkout linux-mips.26.8 (e.g.);\n> (3) Apply the patch created in (1), above;\n\nExcept it'll be \"apply the patches, re-creating history\nas if it had been done with a different base from the\nstart\".\n\n> (4) Tag the result `like-this';\n> (5) Checkout our.21; and\n> (6) Merge with `like-this'.\n> \n\nMerge is not necessary.\n\n> I admit that now that I write the steps out, it seems\n> to make sense ....? Am I understanding correctly?\n> \n\nAlmost. \"git help format-patch\" and \"git help am\" will get\nyou the rest of the way, I think.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"109895","messageId":"200903301440.43601.brian.foster@innova-card.com","threadId":"18634","inReplyTo":"49D0B8BC.2010405@viscovery.net","subject":"Re: [Q] merging from one (kernel) stable to another?","fromName":"Brian Foster","fromEmail":"brian.foster@innova-card.com","sentAt":"2009-03-30T12:40:43Z","receivedAt":"2009-03-30T12:40:43Z","isPatch":false,"sender":{"key":"brian.foster@innova-card.com","avatar":null},"body":"On Monday 30 March 2009 14:19:08 Johannes Sixt wrote:\n> Brian Foster schrieb:\n>[ ... ]\n> > Thanks for the suggestion. I'll have to experiment,\n> > but off-the-top-of-my-head, I think I do want a merge,\n> > so that it's easier to track the history of individual\n> > local changes. Having said that, I'm not entirely sure\n> > I follow your suggestions. What I think you mean is:\n> > \n> > (1) Create a patch which is all (local) changes\n> > (née diffs) from linux-mips.21 to our.21;\n> > (2) Checkout linux-mips.26.8 (e.g.);\n> > (3) Apply the patch created in (1), above;\n> \n> format-patch creates a patch series. You apply the whole series,\n> e.g. with 'git am'. But for this workflow you could also just create\n> a single patch and apply it to linux-mips.26.8, just as you wrote.\n\n Point taken. I was being a bit sloppy there; I well know\n `git format-patch' (which we use in our internal workflow)\n generates a patch series, and that `git am' applies them.\n Apologies for the confusion. Sorry!\n\n> The important point is that you forge this tree into the shape that\n> you finally want to have in the merge (that you will make later).\n> At this point you only have to deal with conflicts and regressions\n> that arise from your own changes, which makes your life much easier\n> than if you also had to deal with conflicts that are outside your\n> own changes.\n\n Gottcha. Thanks for clarifying.\n\n> > (4) Tag the result `like-this';\n> > (5) Checkout our.21; and\n> > (6) Merge with `like-this'.\n> \n> No, you merge with linux-mips.26.8. This will again give you a lot\n> of conflicts. But you do\n> \n> (7) git checkout like-this -- .\n> \n> that is, you overwrite the merge result (that has conflicts) with\n> your known-good tree called \"like-this\". This resolves all conflicts\n> in the way that you wanted them.\n\n Ah! Neat. I think I get it (er, git it?) now ....\n Many thanks for your patient and very helpful replies!\ncheers!\n\t-blf-\n\n-- \n“How many surrealists does it take to | Brian Foster\n change a lightbulb? Three. One calms | somewhere in south of France\n the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!\n with brightly-coloured machine tools.” | http://www.stopesso.com\n"},{"id":"109897","messageId":"200903301451.33956.brian.foster@innova-card.com","threadId":"18634","inReplyTo":"49D0B8BF.2000502@op5.se","subject":"Re: [Q] merging from one (kernel) stable to another?","fromName":"Brian Foster","fromEmail":"brian.foster@innova-card.com","sentAt":"2009-03-30T12:51:33Z","receivedAt":"2009-03-30T12:51:33Z","isPatch":false,"sender":{"key":"brian.foster@innova-card.com","avatar":null},"body":"On Monday 30 March 2009 14:19:11 Andreas Ericsson wrote:\n> Brian Foster wrote:\n> >[ ... ]\n> > (1) Create a patch which is all (local) changes\n> > (née diffs) from linux-mips.21 to our.21;\n> \n> This is wrong. Create several git-patches, each containing\n> the equivalence of one commit (complete with diff, author\n> info and commit message).\n\n Yes, I was being sloppy there. Internally, we use both\n `git format-patch' and `git am', but have a bad(?) habit\n of referring to a patch series as “a patch”. Apologies\n for the confusion. Sorry!\n\n> > (2) Checkout linux-mips.26.8 (e.g.);\n> > (3) Apply the patch created in (1), above;\n> \n> Except it'll be \"apply the patches, re-creating history\n> as if it had been done with a different base from the\n> start\".\n\n Yes.\n\n> > (4) Tag the result `like-this';\n> > (5) Checkout our.21; and\n> > (6) Merge with `like-this'.\n> \n> Merge is not necessary.\n\n I'll going to try in both ways (with and without\n merging) to better understand just what the results are like.\n\n> > I admit that now that I write the steps out, it seems\n> > to make sense ....? Am I understanding correctly?\n> \n> Almost. \"git help format-patch\" and \"git help am\" will get\n> you the rest of the way, I think.\n\n ;-) Well, I did say “RTFM” is useful....!\n\n Many thanks for your patient and very helpful replies.\ncheers!\n\t-blf-\n\n-- \n“How many surrealists does it take to | Brian Foster\n change a lightbulb? Three. One calms | somewhere in south of France\n the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!\n with brightly-coloured machine tools.” | http://www.stopesso.com\n"},{"id":"109900","messageId":"49D0CE95.6020407@op5.se","threadId":"18634","inReplyTo":"200903301451.33956.brian.foster@innova-card.com","subject":"Re: [Q] merging from one (kernel) stable to another?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-03-30T13:52:21Z","receivedAt":"2009-03-30T13:52:21Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Brian Foster wrote:\n> On Monday 30 March 2009 14:19:11 Andreas Ericsson wrote:\n>> Brian Foster wrote:\n> \n>>> (4) Tag the result `like-this';\n>>> (5) Checkout our.21; and\n>>> (6) Merge with `like-this'.\n>> Merge is not necessary.\n> \n> I'll going to try in both ways (with and without\n> merging) to better understand just what the results are like.\n\nIf you get the tree into the state you want and simply want to\nconnect the histories, you can do\n\n git merge -s ours $other_branch\n\nwhich will record the tree from the current commit as the tree\nfor the merge-commit (ie, all changes from $other_branch are\nthrown away, and the merge always succeeds without conflicts).\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"109913","messageId":"46dff0320903300820u3efb26c2x5658afc71096d180@mail.gmail.com","threadId":"18634","inReplyTo":"49D09207.9080407@op5.se","subject":"Re: [Q] merging from one (kernel) stable to another?","fromName":"Ping Yin","fromEmail":"pkufranky@gmail.com","sentAt":"2009-03-30T15:20:00Z","receivedAt":"2009-03-30T15:20:00Z","isPatch":false,"sender":{"key":"pkufranky@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5346?v=4"},"body":"On Mon, Mar 30, 2009 at 5:33 PM, Andreas Ericsson wrote:\n> Brian Foster wrote:\n>>\n>> Whilst this question involves linux(-mips) kernel tree,\n>> it's a git(-related?) question, not a kernel question ....\n>>\n>> We are currently in the process of upgrading our embedded\n>> system from kernel 2.6.21(-ish) to at least 2.6.26.8; and\n>> later, at some time in the future on to 2.6.3x or something.\n>> Going from 2.6.21 to .22 to .23 and so on to .26, then to\n>> .26.1 and so on to .26.8 is “easy” in the sense there are\n>> very few conflicts with our existing baseline (e.g., just\n>> 2 or 3 in 2 or 3 files).\n>>\n>> .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master\n>> \\ \\ \\ \\ \\\n>> .21-stable .22-stable .23-stable \\ .27-stable\n>> .26.8\n>> \\\n>> .26-stable\n>>\n>> But (using 2.6.21-stable and 2.6.22-stable as proxies),\n>> tests indicate that going from .26.8 to .27 or anything\n>> later will have numerous conflicts (100s? in more than\n>> 30 files). Thinking about it, this isn't too surprising\n>> since the -stable branches cherry-pick important/benign\n>> fixes from later revisions.\n>>\n>> What's frustrating is that in essentially all “conflict”\n>> cases, the resolution is simple: Use the later version.\n>\n> The trouble is \"essentially all\", as opposed to \"all\". Git\n> can never know which of the conflicts are which, so it will\n> leave it all up to you.\n>\n> A possibly better approach for you is to \"git format-patch\"\n> your own changes and apply them to a clean 2.6.26.8 tree\n> instead of trying to merge 2.6.26.8 into 2.6.21.\n\nOr just (say, always use rebase instead of merge)\n\ngit rebase -i 2.6.26.8 --onto 2.6.27\n"},{"id":"109926","messageId":"alpine.LNX.1.00.0903301311230.19665@iabervon.org","threadId":"18634","inReplyTo":"200903301024.08848.brian.foster@innova-card.com","subject":"Re: [Q] merging from one (kernel) stable to another?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-03-30T17:31:18Z","receivedAt":"2009-03-30T17:31:18Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 30 Mar 2009, Brian Foster wrote:\n\n> Whilst this question involves linux(-mips) kernel tree,\n> it's a git(-related?) question, not a kernel question ....\n> \n> We are currently in the process of upgrading our embedded\n> system from kernel 2.6.21(-ish) to at least 2.6.26.8; and\n> later, at some time in the future on to 2.6.3x or something.\n> Going from 2.6.21 to .22 to .23 and so on to .26, then to\n> .26.1 and so on to .26.8 is “easy” in the sense there are\n> very few conflicts with our existing baseline (e.g., just\n> 2 or 3 in 2 or 3 files).\n> \n> .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master\n> \\ \\ \\ \\ \\\n> .21-stable .22-stable .23-stable \\ .27-stable\n> .26.8\n> \\\n> .26-stable\n> \n> But (using 2.6.21-stable and 2.6.22-stable as proxies),\n> tests indicate that going from .26.8 to .27 or anything\n> later will have numerous conflicts (100s? in more than\n> 30 files). Thinking about it, this isn't too surprising\n> since the -stable branches cherry-pick important/benign\n> fixes from later revisions.\n\nWhy are you going from .26.8 to .27? Based on the -stable policy, there \nshould be no reason not to skip .26.x between .26 and .27. In fact, it's \nnot unlikely that merging both .26.8 and .27 will introduce bugs when the \nsame issue was fixed in different places in the two branches: a narrow \npatch to paper over the identified problem in -stable and an intrusive \npatch to change some API to make simpler code correct in the mainline.\n\nThat is, the correct way of merging changes from -stable with the latest \nmainline series is always to take the mainline version, even if the \n-stable changes don't conflict at all.\n\nIt should actually be ideal to just merge your local changes directly with \nthe mainline kernel you want to end up using. But you might want to merge \nfirst with earlier mainline kernels in order to get fewer or easier \nconflicts per step.\n\n\t-Daniel\n*This .sig left intentionally blank*"},{"id":"109934","messageId":"20090330182345.GC10030@pengutronix.de","threadId":"18634","inReplyTo":"200903301024.08848.brian.foster@innova-card.com","subject":"Re: [Q] merging from one (kernel) stable to another?","fromName":"Uwe Kleine-König","fromEmail":"u.kleine-koenig@pengutronix.de","sentAt":"2009-03-30T18:23:45Z","receivedAt":"2009-03-30T18:23:45Z","isPatch":false,"sender":{"key":"u.kleine-koenig@pengutronix.de","avatar":"https://gravatar.com/avatar/354b5e3ceb2806a2f1e1e382ac29ddbdad18288654da62b61eb13583a857eee7?d=mp&s=160"},"body":"On Mon, Mar 30, 2009 at 10:24:08AM +0200, Brian Foster wrote:\n> Whilst this question involves linux(-mips) kernel tree,\n> it's a git(-related?) question, not a kernel question ....\n> \n> We are currently in the process of upgrading our embedded\n> system from kernel 2.6.21(-ish) to at least 2.6.26.8; and\n> later, at some time in the future on to 2.6.3x or something.\n> Going from 2.6.21 to .22 to .23 and so on to .26, then to\n> .26.1 and so on to .26.8 is “easy” in the sense there are\n> very few conflicts with our existing baseline (e.g., just\n> 2 or 3 in 2 or 3 files).\n> \n> .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master\n> \\ \\ \\ \\ \\\n> .21-stable .22-stable .23-stable \\ .27-stable\n> .26.8\n> \\\n> .26-stable\n> \n> But (using 2.6.21-stable and 2.6.22-stable as proxies),\n> tests indicate that going from .26.8 to .27 or anything\n> later will have numerous conflicts (100s? in more than\n> 30 files). Thinking about it, this isn't too surprising\n> since the -stable branches cherry-pick important/benign\n> fixes from later revisions.\nAssuming you have your master on top of .21-stable and want to go to\n.26-stable, the following might work better for you:\n\n\t$ git checkout -b mydot26stable .26-stable\n\t$ git merge -s ours .21-stable\n\t$ git checkout master\n\t$ git merge mydot26stable\t\n\nNote this is not tested, just came to my mind...\n\nBest regards\nUwe\n\n-- \nPengutronix e.K. | Uwe Kleine-König |\nIndustrial Linux Solutions | http://www.pengutronix.de/ |\n"},{"id":"109957","messageId":"e51f4f550903302120s62f6056bg95f7a5aca4ec3d@mail.gmail.com","threadId":"18634","inReplyTo":"49D09207.9080407@op5.se","subject":"Re: [Q] merging from one (kernel) stable to another?","fromName":"Kris Shannon","fromEmail":"kris@shannon.id.au","sentAt":"2009-03-31T04:20:20Z","receivedAt":"2009-03-31T04:20:20Z","isPatch":false,"sender":{"key":"kris@shannon.id.au","avatar":"https://gravatar.com/avatar/13a7c0b3c50ffacf54f456e543023fd702898bb134165fa805f019930524151f?d=mp&s=160"},"body":"2009/3/30 Andreas Ericsson \n>\n> Brian Foster wrote:\n>>\n>> Whilst this question involves linux(-mips) kernel tree,\n>> it's a git(-related?) question, not a kernel question ....\n>>\n...\n>> But (using 2.6.21-stable and 2.6.22-stable as proxies),\n>> tests indicate that going from .26.8 to .27 or anything\n>> later will have numerous conflicts (100s? in more than\n>> 30 files). Thinking about it, this isn't too surprising\n>> since the -stable branches cherry-pick important/benign\n>> fixes from later revisions.\n>>\n>> What's frustrating is that in essentially all “conflict”\n>> cases, the resolution is simple: Use the later version.\n>\n> The trouble is \"essentially all\", as opposed to \"all\". Git\n> can never know which of the conflicts are which, so it will\n> leave it all up to you.\n\ngit mailing list \n\nWhat you could do is something like:\n\ngit checkout -b mystable-27 linux-2.6.27-stable\ngit merge -s ours linux-2.6.26-stable\ngit checkout local-changes-26\ngit merge mystable-27\n\nThe extra merge might allow git to distinguish between 26->27\nconflicts and conflicts due to your local-changes.\n\nBTW, when doing these merges between release branches you\nprobably want to increase merge.renamelimit.\n"},{"id":"109982","messageId":"200903310930.34617.brian.foster@innova-card.com","threadId":"18634","inReplyTo":"alpine.LNX.1.00.0903301311230.19665@iabervon.org","subject":"Re: [Q] merging from one (kernel) stable to another?","fromName":"Brian Foster","fromEmail":"brian.foster@innova-card.com","sentAt":"2009-03-31T07:30:34Z","receivedAt":"2009-03-31T07:30:34Z","isPatch":false,"sender":{"key":"brian.foster@innova-card.com","avatar":null},"body":"On Monday 30 March 2009 19:31:18 Daniel Barkalow wrote:\n> On Mon, 30 Mar 2009, Brian Foster wrote:\n> > Whilst this question involves linux(-mips) kernel tree,\n> > it's a git(-related?) question, not a kernel question ....\n> > \n> > We are currently in the process of upgrading our embedded\n> > system from kernel 2.6.21(-ish) to at least 2.6.26.8; and\n> > later, at some time in the future on to 2.6.3x or something.\n> > Going from 2.6.21 to .22 to .23 and so on to .26, then to\n> > .26.1 and so on to .26.8 is “easy” in the sense there are\n> > very few conflicts with our existing baseline (e.g., just\n> > 2 or 3 in 2 or 3 files).\n> > \n> > .21 --> me --> .22 --> .23 ... --> .26 --> .27 --> master\n> > \\ \\ \\ \\ \\\n> > .21-stable .22-stable .23-stable \\ .27-stable\n> > .26.8\n> > \\\n> > .26-stable\n> > \n> > But (using 2.6.21-stable and 2.6.22-stable as proxies),\n> > tests indicate that going from .26.8 to .27 or anything\n> > later will have numerous conflicts (100s? in more than\n> > 30 files). Thinking about it, this isn't too surprising\n> > since the -stable branches cherry-pick important/benign\n> > fixes from later revisions.\n> \n> Why are you going from .26.8 to .27? Based on the -stable policy,\n> there should be no reason not to skip .26.x between .26 and .27.\n\nDaniel,\n\n That's a good question! The policy to-date has been to\n ignore the -stable branches entirely, and go from release\n to release; i.e., .21 to .22 to ... to .26 to .27 et al.\n We (deliberately!) stay several releases behind (being\n bang-up-to-date isn't too important to our market/product,\n but having a robust secure system is extremely important).\n\n The current feeling is we should probably be moving from\n -stable to -stable, i.e., .21-stable to .22-stable to ...\n to .26-stable and later to .27-stable and so on. This is\n based, in part, on observing the changes that are in -stable\n and realizing some of them are highly desirable. This new\n idea/plan of going from -stable to -stable can change if\n there's a good reason. It's currently in a state of flux.\n\n So I somewhat incorrectly described the thinking, mixing\n up our historical practice with the proposed new policy.\n In my defense, my I point out that we are particularly\n interested in some MIPS changes on .26-stable, and, at the\n the moment, have decided to not go to .27 for this cycle.\n (Admittedly, with the release of .29, the decision not to\n go to .27 has been challenged, but the issue hasn't been\n looked into in any detail (yet? as far as I know).)\n\n Anyways, good catch! I take your point. Many thanks.\n\n> In fact, it's\n> not unlikely that merging both .26.8 and .27 will introduce bugs when the\n> same issue was fixed in different places in the two branches: a narrow\n> patch to paper over the identified problem in -stable and an intrusive\n> patch to change some API to make simpler code correct in the mainline.\n> \n> That is, the correct way of merging changes from -stable with the latest\n> mainline series is always to take the mainline version, even if the\n> -stable changes don't conflict at all.\n\n Yep! We don't want to merge changes from -stable\n into master (mainline). That was a mistake in my\n description. Again, thanks for pointing it out.\n\n> It should actually be ideal to just merge your local changes directly with\n> the mainline kernel you want to end up using. But you might want to merge\n> first with earlier mainline kernels in order to get fewer or easier\n> conflicts per step.\n\n Indeed. We are progressing one release at a time.\n (I've been insisting on this!) However, given we're\n not targeting .27 or later at this cycle, and that\n we know there are changes on .26-stable we want/need,\n it's (almost) a dead cert our next release will be\n based on some point in .26-stable (I'm using .26.8\n as a proxy as it's the latest (when I checked) tag\n on .26-stable).\n\n Things are in flux, and suggestions are certainly\n welcome. Thanks for your very helpful observations.\n\ncheers!\n\t-blf-\n\n-- \n“How many surrealists does it take to | Brian Foster\n change a lightbulb? Three. One calms | somewhere in south of France\n the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!\n with brightly-coloured machine tools.” | http://www.stopesso.com\n"}]}