Unless you are one of the core kernel developers, you always communicate your changes via patches posted to mailing lists. However, if your patch is going to take more than ten minutes to write you need to keep up to date with the upstream kernel source, because otherwise you'll end up hopelessly behind. The problem is that you always need to keep your changes on the top, because you need to be easily able to export them as a patch against the upstream tree at any point.
I call this being on the "edge" of kernel development -- there is nobody further out from the middle than you. Generally, I have found git and any of the wrappers quite painful, but thanks to Matt Chapman I gave Mercurial (hg) a go, and it is perfect.
Firstly, clone a new tree
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 any point in time. Next, clone a working directory where you will be doing your development.
hg clone linux-2.6 linux-2.6-working
Start doing your work on the linux-2.6-working tree; make commits as necessary as you develop major parts of your work.
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 -l kernel-import
You can then get all your changes against the kernel you have downloaded from with
hg diff kernel-import:tip
Now several hours/days/weeks later 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
Now pull into the update tree your development tree. This will (should) have the effect of just grabbing all your changesets.
cd linux-2.6-update hg pull ../linux-2.6-working
Now your project has multiple heads -- 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 conflicts, 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 local tag at the start of your changesets by looking at hg log and using hg tag -l kernel-import first-of-your-changesets-revision-number (is there a better way to do this?).
hg tag kernel-import
So your changesets 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 patches (for sending to lists, etc) with
hg export kernel-import:tip
Now continue your work in the update tree you just created. Commit as much as you like doing all the development you require, at any time you can use the export from the tag you created to get a patch of your work.
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.