Version 23 (modified by Juri, 8 years ago) (diff)


Git Repository URLs


Other Git Introductions

Please note the links in this documentation take you to the v1.5.6.5 documentation. Please check the documentation apropriate for your version of git.


Git Tutorial]

[ Everyday Git] -- Very dense guide that introduces 95% of the git commands you'll ever use.

While we are a kernel project, the repository itself is not laid out like the kernel, but this is still a good guide. Also, in the future it

would probably be more convenient hacking to be a "branch" off Linus's

git tree.

CompScis?] -- Fundamentals of git from a unique point of view.

Magic] -- Long and detailed guide to git written while learning git, despite not understanding the manual.


Shipping Quality Code with Git] -- Guide to making you commits "look

good" that actually give a lot of nice git tricks. Be sure to read the comments, they provide good cautions about these tricks from Linus.

general git questions.

Retrieving the source with git

First, you'll need to make sure you have git and quilt installed, as well as the ability to compile a normal linux 2.6.17 kernel. after that,

run one of the two following commands (depending on whether you have

shell access to the server or not)

git clone ssh://$ linuxPMI


git clone linuxPMI

you'll only use this command once. This command pulls down all the data

in the repository and generally prepares your system to work with that

repository. The git-clone(1) man page has the gory details.

What is all this stuff?

under the linuxPMI directory created by that command, you'll find a 2.6 directory, and inside that you'll find directories for 'kernel', 'notes', and 'tools'. the 'kernel' directory contains our kernel, its patches, and utilities for building it. the 'notes' directory contains the documentation written on the patches so far. the 'tools' directory contains our old migration torture tools, for testing purposes.

Building a (testing only, BROKEN!) kernel

to build a kernel, run the following commands:

cd 2.6/kernel/
./devutils/setupenv env build

this creates a directory named build, with the current patches applied to it.

Where are the Patches?

if you're interested in looking through the patches, they're located in the 2.6/kernel/2.6.17/linuxpmi/ directory. the old openmosix patches are

located in the 2.6/kernel/2.6.17/openmosix directory, for historical


What do I do when this doesn't work?

Pitch In! We're looking for volunteers to help with all sorts of tasks. join the mailing list, or drop by #openmosix on!

Conflict Resolution Procedures

if a 'git push' notifies you you've got a conflict, do a 'git pull' to have git intersperse notes amongst the file in conflict. now edit the file until it 'looks right' again, being mindful of both sets of changes, do a 'git add' and 'git commit' to create a new transaction, and 'git push' the file up to the tree.

Notes on Git Commands


git add my_new_file

Anytime you create a file, you use this command to tell git that it should begin change tracking on it. Git will record the current contents of the file in the "index", a sort of working area that's not tied directly to the file system. You will also run this command against an existing file that you've changed to record the new contents in the index.


git mv a_tracked_file another_tracked_directory


git mv a_tracked_file my_new_file_name

This command is used to notify git of moves or renames. Updates the index.


git rm im_a_gonner

This command tells git that a file is no longer part of the tracked tree. Updates the index.


git status

Has git report on the differences between the tip of the current branch,

the index, and the filesystem. It will list new files to be added to

the tree, renames, removals, files that have changed that will be committed, and files that have changed but not recorded to the index. Generally you'll want to run this before a commit to confirm what you are committing.


git diff


git diff --cached


git diff HEAD

This is a far more detailed version of status whose output is a unified diff. A simple git diff tells you changes between the index and your working tree i.e. changes you haven't told git to record yet. The more verbose git diff --cached gives the difference between the index and the last commit i.e. the changes you'll scheduled for commit.

Finally git diff HEAD gives the sum total differences between the filesystem right now and the last committed version.


git commit


git commit -a


git commit some_files that_were_changed

This command records changes to your local git tree, moving the head/tip

forward. Git will open your $EDITOR so that you can enter a

commit message (empty messages are not allowed) or you can specify one with the -m option. With no options (other than -m), changes already recorded to the index are committed. With the -a option, files that are tracked are committed even if their changes have not been recorded in the index. -a is short for all, but it doesn't track additions or renames so you may have to use other git commands to schedule those changes for commit even if you are using it. If filenames are specified, changes between the last commit and the working

tree to those file are committed, completely bypassing the index.


git push

git commit only records changes to your local repository, eventually you'll probably want to send that information back to the git

repository you cloned from. This command does just that.


git pull

Assuming you aren't the only one working from the repository you cloned from it will change from time to time. This command fetches the new data merges it into your local repository.

Other Git


By analogy: .cvsignore -> CVS <-> .gitignore -> git

Git refuses to track empty directories, but an empty .gitignore in a otherwise empty directory will convince it to check in the directory, just like CVS. Even the file format is the same.

The Rest

There's plenty of good resources for learning git available across the web, some of which are linked above. This page will probably give you the bare minimum you need to be a useful committer, but that documentation is more complete and better maintained.