git help needed for 2.6.34 kernel branch revival

[Daniel Drake]

On 19 August 2010 09:43, Martin Langhoff <martin.langhoff at gmail.com> wrote:
> 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.

Thanks for the advice. This is effectively the "399 patches" approach
I mentioned.

> 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).

For the 2.6.31 to 2.6.34 move, no rebasing happened. The 2.6.34 kernel
tree was simply merged into the 2.6.31.6 + olpc tree.
I think this was a mistake, given that 2.6.34 doesn't logically follow
on from 2.6.31.6.

I'm in agreement that the right thing to do is rebase (as you
outlined), especially after starting the process of doing this. This
also means that merging linux-stable is OK (which is not a bad idea at
all). And we should put more effort into upstreaming so that the
amount of rebasing work is not so great each time.

Thanks,
Daniel