The Kernel "Nobody" Guide to git

If you are a kernel "nobody" that means you're not an upstream maintainer, and are very unlikely to push your changes either at all or only via patches in emails. You're not a maintainer or a core developer, you're just a "nobody".

Hoepfully this is a minimal guide to getting going with git

Get git

This is quite straight forward, plenty of other docs

It seems most of the core developers don't use the wrapper stuff like cogito. For this reason I would probably reccommend you learn your way around git.

Get a kernel tree

git clone git:// linux-2.6

This takes a while

Some terms

Start working on your own branch

git checkout -b devbranch

You can check where you are with

$ git show-branch
* [devbranch] Merge git://
 ! [master] Merge git://
  ! [origin] Merge git://
+++ [devbranch] Merge git://


$ ls -l .git/HEAD
lrwxrwxrwx  1 ianw ianw 20 2005-11-14 14:33 .git/HEAD -> refs/heads/devbranch


$ git-symbolic-ref HEAD

Start working on your new features

The underlying git repository is a collection of objects (Blobs, for binary objects) that lives in your .git directory. There is a cache in between your working directory and the object database; you need to tell the cache what is happening with the git-update-cache command in its various incarnations. You can then commit your changes to the underlying object database.

$ echo "hello" > Documentation/newfeaturedoc.txt
$ git-update-cache --add Documentation/newfeaturedoc.txt
$ git commit Documentation/newfeaturedoc.txt

To see what you have modified, and if you need update the cache try

$ git-update-cache --refresh

What is happening underneath

The commit process actually writes a tree object back into the object database. A tree object is a heirarchy of pointers to blobs and other tree objects that describes the overall kernel revision. When you commit the tree, a commit object is created which points to the top of the tree. You can see the commit object

$ git-cat-file commit $(cat .git/HEAD)
tree 27a73405d3652dc6771fab28721b70e6d44ff47a
parent b1459461f1e0abd5c28317d6bff6f2ca612a719d
parent 1b40efd772f4419fbc1a8940506424246985c333
author Linus Torvalds <> 1130647686 -0700
committer Linus Torvalds <> 1130647686 -0700


Thus the parents are pointers to previous commit objects, which allow you to build a path backwards describing what was commited. To do this you look at the tree object for the commit, which holds all the information about which underlying blobs and child trees make up that commit

$ git-ls-tree  27a73405d3652dc6771fab28721b70e6d44ff47a
100644 blob 5014bfa48ac169e0748e1e9651897788feb306dc    .gitignore
100644 blob ca442d313d86dc67e0a2e5d584b465bd382cbf5c    COPYING
100644 blob 5b1edf3a38a22bc9f7a7d668d4290434342d1bf1    CREDITS
040000 tree 015ff39c522d86e5c340afa715ecb2820e6541d3    Documentation
100644 blob 79003918f37f2593e157778734f2bb83d131abb1    Kbuild
100644 blob e88d193d42f8f7031b86900cb215806753991b52    MAINTAINERS
100644 blob 79601320ac3e371666593abcca5820efdbae5caf    Makefile
100644 blob d1edcc7adabe4a1dfd8efbdb3d26777a8526b044    README
100644 blob f9da827a0c1880154757981e1430f01f071181f2    REPORTING-BUGS
040000 tree 221fff413728637507a78bf43571ce132a26a2c1    arch
040000 tree c18c24a4ccebf9780ff1868e489f84248b2d9992    crypto
040000 tree 57ce03ceed524b52b4a4d85279dd008dc71ff82d    drivers
040000 tree 82bf67f66ff0af2796daafc0745dd7790e473088    fs
040000 tree 7b7c49677193a3bb925af186e500890e6bb53295    include
040000 tree 01131b07eaab1767073a94f2c7d682270d36c1dd    init
040000 tree e571358edb157525466bc4e996db6196933ad58e    ipc
040000 tree 895ee11f8401f36416febd9d345143e7e7f2e4ac    kernel
040000 tree 78d83a41164712839a20d2257a0e3ace74832db7    lib
040000 tree 9e34c7bbf0324708daf4db2a3aa5d070c3c74834    mm
040000 tree 0874e46ac8c3d7c355c50d8c4a0925c6f1b7ebb4    net
040000 tree 678eae14dcd1fd802e2cb1a8475a3a71b31fe4dd    scripts
040000 tree 3e9af47b4e217a8deb66acb602405d08aa3f6d3b    security
040000 tree f2f05ff38162c991d1773bcfdb4c8f09d09200db    sound
040000 tree bc589b0ffba8941b7f7574b71ddec795e2217107    usr

Possibly tag

Tagging might make it easier to come back later with ongoing development

$ git tag devtag

Create a diff to send to the list

$ git diff master..HEAD
diff --git a/Documentation/newfeaturedoc.txt b/Documentation/newfeaturedoc.txt
new file mode 100644
index 0000000..73debc6
--- /dev/null
+++ b/Documentation/newfeaturedoc.txt
@@ -0,0 +1,3 @@
+this is something after devtag
\ No newline at end of file

or possibly, if you want to diff against a tag

$ git diff master..devtag
diff --git a/Documentation/newfeaturedoc.txt b/Documentation/newfeaturedoc.txt
new file mode 100644
index 0000000..ce01362
--- /dev/null
+++ b/Documentation/newfeaturedoc.txt
@@ -0,0 +1 @@

The easiest way to prepare the diff for submission is

$ git format-patch master devbranch
* 0001-very-cool-new-feature-one.txt
* 0002-another-new-feature.txt

This creates e-mail messages formatted properly, according to Documentation/!SubmittingPatches.

Pull upstream changes and merge them in

Switch back to the "master" branch

$ git checkout master

and pull down changes

$ git pull

This should bring the master branch back up to date with the latest Linus tree

Now switch back to your dev branch

$ git checkout devbranch

and pull the master branch locally.

$ git pull . master

Overview Diagram


IA64wiki: KernelNobodyGuideToGit (last edited 2009-12-10 03:13:47 by localhost)

Gelato@UNSW is sponsored by
the University of New South Wales National ICT Australia The Gelato Federation Hewlett-Packard Company Australian Research Council
Please contact us with any questions or comments.