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