Git is the version tracking system used by the Linux kernel and increasingly many others. Why?

• it is fast
• it is compact
• it is fully distributed
• it is widely supported and used
• it let us import upstream changes directly

Web interface: http://git.rsbac.org/ GIT access:

• git://rsbac.org/linux-2.6-next.git - the development repository for the UNstable RSBAC, tracking the newest kernels (this is not tracking linux-next!)
• git://rsbac.org/linux-2.6.git - the development repository for the stable RSBAC, tracking the newest kernels
• git://rsbac.org/linux-2.6.35.y.git - tracking longterm support for 2.6.35
• git://rsbac.org/linux-2.6.32.y.git - tracking longterm support for 2.6.32 (and so on)

Developers may replace git://rsbac.org/ by ssh://rsbac.org/daten/git/

Coming from SVN, SVK?

Forget about the classical file structure. GIT is fully distributed, thus every repository is your own. A common mistake is to try to use GIT as if it were SVN or SVK (or CVS for that matter). It won't work out.

When you push your changes upstream, you are sending your differences for inclusion, you are not synchronizing with upstream. That's the difference. It is a very important difference.

On a shared upstream repository (e.g. the RSBAC developers shared repository), you must be careful of what you push, knowing the state of the upstream repository might end up being different than your repository state. GIT provides many safe-guards, yet, it is possible to make things go wrong.

Also: there are no trunk, tags, branches directories. Only branches!

Tags are special commits which are immutable, included in the branches. They are not standalone branches.

Branches can be merged to each other. In fact, GIT is made to do that all the time.

Every commit is marked with a unique SHA1 sum. When you merge, common ancestors (identical SHA1 sum) are found, no matter which branch you are using, Linus tree, RSBAC tree, your friend tree.. if there's common ancestors they will be found and used.

The default branch is usually called master (instead of trunk) but not necessarily.

However, when you are updating from upstream, only exact direct ancestors will be fast-forwarded - this means, erased by the upstream copy, for example updating from Linus tree, all untouched files in your repository will be fast-forwarded, any touched file will be merged, even if you corrected the change manually.

That's because there will be no direct ancestor (the SHA1 hash of the last commit will differ), so GIT will NOT fast-forward even if the files are identical.

To avoid this, simply never ever commit stuff that do not belong to RSBAC code. If you do, revert it cleanly before pushing to the shared upstream RSBAC repository.

Defaults for commits:

# git config --global user.name "FirstName LastName"
# git config --global user.email "user@example.com"

Enable coloring (recommended):

# git config --global color.ui "auto"

Enable multi-core CPU detection:

# git config --global pack.threads "0"

Enable maximum memory usage limit (recommended for systems with 2G+ of RAM):

# git config --global   diff.renamelimit "0"

(As developer)

# git clone ssh://rsbac.org/daten/git/linux-2.6.git

(Anonymous)

# git clone http://git.rsbac.org/linux-2.6
# git clone git://rsbac.org/linux-2.6

Note that this gives you the same repository, but setup your git config file differently, so developers can push their changes by default via SSH. git: is faster than http:.

# git pull --ff-only ssh://rsbac.org/daten/git/linux-2.6.git

FF only ensure you only get fast-forward commits, and no merge attempt. This is necessary when the upstream repository is regularly rebased, which is the case for us.

# git push ssh://rsbac.org/daten/git/linux-2.6.git master:master

The first master is “your side” branch, the second master is RSBAC's side branch (which is always master).

/!\ Danger! Failure from doing this properly might actually kill your cat this time /!\

Pulls from kernel.org must be rebased as such:

# git pull --rebase git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

or for example if you have a shortcut:

# git pull --rebase linux26

This will fast-forward all the changes from the linux-2.6 repository, then re-apply your changes on top, ensuring RSBAC always apply as a clean patch and that there are no non-RSBAC commits.

If this fail, then either:

• Some RSBAC commits need manual merge (that is ok)

• Some commits are not RSBAC related (that is not ok, kill them, unless you never plan to push to the RSBAC shared repository)

Pushing back is tricky, because as you have rebased, your branch do not has proper ancestors on rsbac.org. Thus we have to force the push if we don't want GIT to try to merge.

# git push -f ssh://rsbac.org/home/user/kang/linux-2.6.git master:master

or

# git push -f origin

This will delete any commit in between, so be sure you have pulled from RSBAC first.

• If your origin is rsbac.org and not kernel.org, you may want to add an additional remote branch to track:

# git remote add linux26 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
# git fetch linux26
# // You can now address this branch as linux26/master for diffs and merges

• Signed tags

git is a bit stupid about tag signing. Yeah, really. If you use for example, kang@rsbac.org as your git commit email, you need to own a default primary gpg key with that email. If like me, you do not have that, but instead, kang@rsbac.org is an alias for another primary gpg key (=another email), you have to tell git or it won't find out, and it will look like your missing your private key while you're really not.

# git tag -u kang@rsbac.org -s my_tag_name

Taken from: http://git.wiki.kernel.org/index.php/GitCheatSheet

Use a GUI log browser! For example: gitk or gitg, but there are many others.

This gives you a local version of “git web” basically.

Speaking of which, another must have the linux-2.6 master git web interface:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary

And the RSBAC one:

http://git.rsbac.org/

This method should in theory never be needed anymore. However, the information is kept in case anything really wrong happens.

Recover the repository after many non-RSBAC commit

While this should not happen, it could be that you commit a non-RSBAC group of files in the Linux tree, which will break “fast forward” merging and conflict on non-RSBAC committed files while pulling from the Linux upstream (linux-2.6.git).

In that case, there is a solution:

1. git clone git:git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 - cd rsbac-2.6 ; git checkout master #or whatever branch you need to fix - diff -uprN -x .gitignore -x autoconf.h -x rsbac -x Documentation/rsbac -x .git linux-2.6 rsbac-2.6 > /tmp/out.patch - rsbac-misc/scripts/checkhunks.py /tmp/out.patch 'diff -uprN' #check it doesnt find any non-rsbac change, else review your patch - cd linux-2.6 ; patch -p1 < /tmp/out.patch - cd linux-2.6 ; git pull -s ours ../rsbac-2.6 master #or whatever branch you need to fix - git status - remove all untracked files if any - they're not part of Linux anymore - remove all modified files with no rsbac code: * git status #edit and clear up by hand whatever is not a modified file (you can keep the original formatting, else next command lines will need to be changed also) * for i in $(awk '{print $3}' /tmp/a); do grep -i RSBAC $i > /dev/null || git checkout $i ; done - a new git status should give you all the files that are RSBAC related and still need to be committed - git diff > /tmp/b - rsbac-misc/scripts/checkhunks.py /tmp/b 'diff –git' #check it doesnt find any non-rsbac change, else review your files ! - check all remaining files by hand: * git status > /tmp/b #edit and clear up by hand whatever is not a modified file again * for i in $(awk '{print $3}' /tmp/b); do git diff $i > /tmp/a; vim -o /tmp/a $i; done * with this command you'll see a diff, “-” lines are the ones you need to add in the bottom (original) file (unless they're required to be removed for RSBAC code), “+” lines are the ones you need to remove (unless they're RSBAC code) * if you're using vim, don't use :wqa or the script will stop, just use :w then :qa - commit