Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?

From: Junio C Hamano <junkio@cox.net>
Date: Mar 29, 2006, 02:26 UTC
Message-ID: <7vmzfac7gn.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <1143596622.2481.10.camel@mattlaptop.metaesthetics.net>

Matt McCutchen <hashproduct@verizon.net> writes:

> I made a customized Linux kernel based on 2.6.15.6 by cloning the stable
> 2.6.15 kernel repository (which was then at version 2.6.15.6) and making
> several commits.  Now I would like a Linux kernel based on 2.6.16 with
> the same customizations.

Drawing ancestry graph would help visualizing what you want to achieve. You have:

       v2.6.15
    ---o
        \ 
         \
          \                 
           o---o---o v2.6.15.6
                    \
                     x---x---x v2.6.15.6-matt

where x---x---x are your own changes, and you want:

       v2.6.15           v2.6.16
    ---o---o---o---...---o---o
        \                     \
         \                     y---y---y 2.6.16-matt
          \                 
           o---o---o v2.6.15.6
                    \
                     x---x---x 2.6.15.6-matt

to happen, where y---y---y are analogous to x---x---x.

Assuming your branches are:

        origin - v2.6.15.6 (from stable team)
        master - your changes (2.6.15.6-matt)

you could:

        $ git fetch git://../torvalds/linux-2.6.git tag v2.6.16
        $ git checkout -b 2.6.16-matt v2.6.16
        $ git format-patch origin master | git am -3

Alternatively, you might want to do a real merge:

       v2.6.15           v2.6.16
    ---o---o---o---...---o---o
        \                     \
         \                     \ 
          \                     m 2.6.16-matt
           o---o---o v2.6.15.6 /
                    \         /
                     x---x---x 2.6.15.6-matt

Presumably the stable team backported safer changes from the history between v2.6.15-v2.6.16, and the way things are fixed are probably quite different from the equivalent fixes in the development track that led to v2.6.16 (because what's being patched has also changed), so it is very likely you would see serious conflicts during this merge. If you do not understand what the stable team did in order to reimplement certain fixes, you would have a very difficult time deciding on how to resolve conflicts with this merge.

At that point it would not be a git question but the kernel question I am not qualified to answer ;-), but it might be an interesting exercise.