On Tue, 28 Mar 2006, Matt McCutchen wrote:
>
> 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. This seems to be a very simple task, but I
> have been trying various combinations of git commands for several days
> and have not figured out how to do it.
>
> I believe that means I should pull the 2.6.16 kernel into the "origin"
> branch and then rebase the "master" branch,
Don't "Pull". "Fetch".
"Pull" implies a merge, which is not what you want.
> To this end, I switched my remote file to point to the
> 2.6.16 stable repository and tried to pull. The result was not what I
> wanted. The situation is complicated by the fact that 2.6.15.6 is not
> an ancestor of 2.6.16. The warning in the man page about branches that
> are modified nonlinearly seems to apply.
Just realize that you can have any number of branches, and instead of
forcing "origin" to be something that it simply is not, just create a new
branch called "linus".
Make that point to my tree, and do
git fetch linus
to update it. It really is that easy.
Exact commands something like this:
(1) Edit your .git/remotes/linus file so that it has the following
contents:
URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Pull: refs/heads/master:refs/heads/linus
(2) Use that to fetch my tree as the "linus" branch:
git fetch linus
and now you have at least a nice new branch that contains the "standard"
kernel. At which point you just need to do
(3) rebase the work since "origin" onto "linus":
git rebase --onto linus origin
I really really despise the "git rebase" command line syntax, and I find
it very non-inuitive, but what this does is take your current branch,
compare its contents to "origin" (ie where you started from), and then
just rebase the commits onto the state that is "linus".
[ Junio: syntax comments:
Personally, I think the rebase syntax sucks, because the _natural_ way
to do it is to just describe the set of commits to rebase the same way
we describe all _other_ commit sets: as a "begin..end" sequence.
So I think rebase _should_ work something like this:
git rebase origin.. [--onto] linus
ie just giving an arbitrary range. This is even more noticeable for
"git-format-patch", where that insane "<his> [<mine>]" syntax is even
worse, for no good reason, when again it should really just work like
"git diff" where giving a single revision implies a single revision, and
giving a range implies a range, and no strange "mine" vs "his" rules ]
Oh well. Syntax rant over.
Linus
-
: 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