Git is the version tracking system used by the Linux kernel and increasingly many others. Why?
Web interface: http://git.rsbac.org/ GIT access:
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:
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.
# 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
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
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:
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:
:wqa
or the script will stop, just use :w
then :qa
- commit