git help needed for 2.6.34 kernel branch revival

[Martin Langhoff]

On Tue, Aug 17, 2010 at 5:01 PM, Daniel Drake <dsd at laptop.org> wrote:
> It would be nice to be able to use his work, given that it appears a
> big chunk of the work is already done. But there are 2 complications:

Hi Daniel

I think I know what you want -- and I'm an old git hand. Should be able to help

You have an "oldish" 2.6.31 + patches and you want to "rebase" those
onto 2.6.34, without getting tangled with. So the first step would be

 get the latest of 2.6.31
 # git fetch

 extract the "not upstream" patches
 # git format-patch -o mypatches 2.6.31..2.6.31custom

 checkout a "rebasing" branch
 # git checkout -b testrebase 2.6.34
 git am mypatches

And now you get to go through the pain of applying each patch, dealing
with conflicts, etc.

git-rebase is actually a trivial wrapper around git-format-patch and
git-am -- in this case you know better how to choose the patches to
try to rebase.


> On a separate note, I guess it would make sense for OLPC to define a
> policy where -stable updates are not brought into the OLPC kernel
> tree. This would avoid this headache in future, as the history would
> flow consistent with Linus' tree.

I would rule out unfounded merges, but if there is a good reason, we
should just do it. Probably that's how we've been rolling anyway.

We _always_ have some custom patches for our new/current HW, so we are
always playing the rebase game when we move to a new kernel branch.
It's not like we'll be able to avoid this (as long as we keep
innovating).

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff