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;
(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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
