Fringe Kernel Work

I define "fringe" kernel work as that done by someone who is not a core developer, and who only communicates back to the community via patches. You are probably developing the latest and greatest kernel feature, and need to keep up with the official release while you do it, but be easily able to create your patch set at any time.

Clone Upstream

hg clone http://www.kernel.org/hg/linux-2.6/

This tree you will never touch directly; it is a copy of where Linus is at

Clone Working

hg clone linux-2.6 linux-2.6-working

Start doing your work on the linux-2.6-working tree; make commits as necessary, etc.

You will want to tag your first commit to make it easier to create diffs of your work. Use a local tag, because it is only for your reference within the local tree. So after your first commit do

hg tag kernel-import

or some similar tag. You can then get all your changes against the kernel you have downloaded from with

hg diff kernel-import:tip

Update time

It is now several days/weeks later, and you need to update your changes against the latest upstream versions.

Firstly, update the upstream tree

cd linux-2.6
hg pull

There shouldn't be any conflicts or issues, because you have not changed anything locally

Now create a new update tree, cloned from the latest upstream version (just as you did when you started)

hg clone linux-2.6 linux-2.6-update

Pull into the update tree your dev tree

cd linux-2.6-update
hg pull ../linux-2.6-working

Merge

At this point your project has MultipleHeads -- one from your old working tree and one from the new tree you are merging into.

You will now need to merge the pulled changes into the new update tree. Do this with

hg update -m

Hopefully there won't be any conficts, but if there are you will have to resolve them.

Once done, the final step is to commit your changes into the new tree.

hg commit -m "merge to new linus tree"

Now create a tag again, so you can easily refer to just your changes later

hg tag kernel-import

Export your patches

Your changeset should now be on the the tip of the update tree. So the update tree becomes the new working tree, and you can archive the old working tree.

You can export your changesets with

hg export kernel-import:tip

What you probably want though is just the difference between what is the latest tip of the tree and where you imported. Use the diff command to get this

hg diff -r kernel-import

Continuing Work

Now continue your work in the update tree you just created. Commit as much as you like doing all the development you require

You can use the export from the tag you created to the tip at any point to get all your changes against the underlying upstream.

Eventually you will need to re-sync with upstream again. At this point repeat the process; make a new update tree and pull your working tree into it. Archive the old working tree and continue development on the new 'update' tree.