Dan Munckton's Home Page

Following on from my previous posts I’ll now make some notes on how to synchronise with the upstream kernel Git HEAD.

The KernelTeam’s KernelMaintenance page does mention a little about this but provides no examples or detail. I found out what was necessary by sending questions to the kernel team mailing list.

In my repository the “origin” repository is an Ubuntu one (ubuntu-intrepid-ports) as this is where I cloned from. But originally this will have been based on a repository from git.kernel.org. So for convenience, we can add a git “remote” definition for our target upstream kernel.org repository so that we can refer to it by a simple name. In this case I’ll just use the name of the upstream tree, linux-2.6.25.y. linux-2.6.25.y is the stable tree for maintenance releases of the 2.6.25 kernel which the ubuntu-intrepid-ports kernel is currently based on.

git remote add linux-2.6.25.y git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.25.y.git

Now we need to fetch all the new upstream changes into our repository. This doesn’t make any changes to our current branch it just downloads upstream revisions into a remote-tracking branch in the background. You can view remote-tracking branches by running git branch -r, you should see linux-2.6.25.y/master listed.

git fetch linux-2.6.25.y

Next we can see what new revisions are available upstream by listing logs from our HEAD through to the HEAD of the upstream remote-tracking branch.

git log HEAD..linux-2.6.25.y/master

We can also see which of our local changes will be rebased by asking git log to show us commits which are in the HEAD but not in the remote. For ubuntu-intrepid-ports this will be all commits which add to or modify the packaging scripts in the debian/ directory, and any other special patches which have been applied. Most of the commit logs for these revisions should start with "UBUNTU:".

git log linux-2.6.25.y/master..HEAD

Now we’re ready to actually rebase. Run the following command. You should see lots of output from git as it saves away local changes, resets back to the last commit pulled from the remote, pulls in all the new revisions from the remote, then replays all our commits on top.

git rebase linux-2.6.25.y/master

That’s it. We’ve resynced with upstream. Now we’re ready to build and test.

If you’re happy the tree is in a good state the next job is to make your updates public. If you have been allocated a git tree on kernel.ubuntu.com you can push the changes there. Otherwise you’ll need to investigate other ways of hosting a remote git repository.

Add a “remote” definition for your public repo. In this example I’m accessing the remote repo using SSH as the transport.

git remote add mypublic myusername@myhost:/path/to/git/repos/dmunckton/ubuntu-intrepid-ports.git

You have to force-push the changes to your remote public tree because where we’ve rebased our history has completely changed. Any history already in your public tree will completely different. The -f option to git push forces it to make the remote repository reflect your local changes. If you don’t do this the push will fail.

git push -f mypublic master

Be careful to warn anyone following your public tree as this type of push will prevent easy tracking using git pull. They will need to follow the instructions in the KernelGitGuide wiki page to track your changes.

As usual if you find any innaccuracies or mistakes please do leave a comment.