git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
BFBrian Foster <brian.foster@innova-card.com>
Date
Mar 30, 2009, 12:40 UTC
Message-ID
<200903301440.43601.brian.foster@innova-card.com>
In-Reply-To
<49D0B8BC.2010405@viscovery.net>
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
Previous: Johannes SixtNext: Andreas Ericsson
Message 6 of 14 in “[Q] merging from one (kernel) stable to another?”
  1. Brian FosterMar 30, 2009
  2. Andreas EricssonMar 30, 2009
  3. Johannes SixtMar 30, 2009
  4. Brian FosterMar 30, 2009
  5. Johannes SixtMar 30, 2009
  6. Brian FosterMar 30, 2009
  7. Andreas EricssonMar 30, 2009
  8. Brian FosterMar 30, 2009
  9. Andreas EricssonMar 30, 2009
  10. Ping YinMar 30, 2009
  11. Kris ShannonMar 31, 2009
  12. Daniel BarkalowMar 30, 2009
  13. Brian FosterMar 31, 2009
  14. Uwe Kleine-KönigMar 30, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.