Releases

Current version
Git/Latestdiff: 1.5.6

Latest Snapshots
Produced after each commit or rebase to new upstream version

GIT
RSBAC source code, can be unstable sometimes

Events

No events planned

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

--- documentation:dev:scm:git [2011/02/15 16:31]
127.0.0.1 (old revision restored)
+++ documentation:dev:scm:git [2011/02/22 12:29]
127.0.0.1 (old revision restored)
@@ Line 2: / Line 2: @@
 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
+  * it is widely supported and used
   * it let us import upstream changes directly
-A simple example:
+====== RSBAC GIT Repositories ======
-The current rsbac-2.6 svn/svk repository is 1.2G, the same git repository is 367M.
+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)
+===== Getting started, setup the repository =====
+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.
+==== The important stuff ====
+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.
+==== Other differences: ====
-===== Getting started, setup the repository =====
-Comming from SVN, SVK?
-Forget about the classical file structure. Git is fully distributed, thus every repository is **your own**.
-When you push your changes upstream, you are sending your differences for inclusion, you are not synchronizing with upstream. That's the difference.
 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.
+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!
+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.
+==== Wait, that's important too ====
+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.
 === Setup ===
@@ Line 51: / Line 70: @@
 === Fetch it (technically, fetch pull and checkout) ===
-(As developper)
+(As developer)
   # git clone ssh://rsbac.org/daten/git/linux-2.6.git
@@ Line 62: / Line 81: @@
 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://''.
-=== Fetch a remote branch ===
+=== Pull it ===
-  # git branch -a
+  # git pull --ff-only ssh://rsbac.org/daten/git/linux-2.6.git
-[...]
-  remotes/origin/rsbac-1.4-2.6.33
-  # git checkout -b rsbac-1.4-2.6.33 origin/rsbac-1.4-2.6.33
-=== Update your RSBAC kernel release (reference only, change values!) ===
+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.
-  This updates the 2.6.33 kernel "stable" branch
+=== Push it (developer only) ===
-  # git pull ssh://rsbac.org/daten/git/linux-2.6.git rsbac-1.4-2.6.33
-  This updates the master "unstable" branch (this will take both Linus tree changes and RSBAC changes)
+  # git push ssh://rsbac.org/daten/git/linux-2.6.git master:master
-  # git pull ssh://rsbac.org/daten/git/linux-2.6.git master
-  Update the master with changes from Linus's Linux tree (=latest possible Linux kernel)
+The first master is "your side" branch, the second master is RSBAC's side branch (which is always master).
-  # git pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
-=== Solve conflicts ===
+=== Pull from non-rsbac.org & push back ===
-I suggest you install a merge tool, like vimdiff, meld, or kdiff.
+**/!\ Danger! Failure from doing this properly might actually kill your cat this time /!\**
-  # git mergetool
+Pulls from kernel.org must be rebased as such:
-When solving, make sure you have a new line between RSBAC code and kernel code. This will allow future changes to be auto-merged more easily when possible.
+  # 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:
-=== The cheat sheet (this is where you find all common commands) ===
+  # git pull --rebase linux26
-Taken from: http://git.wiki.kernel.org/index.php/GitCheatSheet
+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.
-{{documentation:dev:scm:git-cheat-sheet-medium.png|}}
+If this fail, then either:
+  * Some RSBAC commits need manual merge (that is ok)
-=== Ease up your tasks ===
+  * Some commits are not RSBAC related (that is not ok, kill them, unless you never plan to push to the RSBAC shared repository)
-Use a GUI log browser!
+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.
-For example: gitk or gitg, but there are many others.
-This gives you a local version of "git web" basically.
+  # git push -f ssh://rsbac.org/home/user/kang/linux-2.6.git master:master
-Speaking of which, another must have the linux-2.6 master git web interface:
+or
-http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
+  # git push -f origin
-And the RSBAC one:
+This will delete any commit in between, so be sure you have pulled from RSBAC first.
-http://git.rsbac.org/
+=== Other tasks ===
-=== Advanced tasks ===
   * If your origin is rsbac.org and not kernel.org, you may want to add an additional remote branch to track:
-  # git remote add upstream git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
+  # git remote add linux26 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
-  # git fetch upstream
+  # git fetch linux26
-  # // You can now address this branch as upstream/master for diffs and merges
+  # // You can now address this branch as linux26/master for diffs and merges
-  * Diff against stable sub releases (2.6.33.2 for example)
-Get the tags from the stable git repos:
+  * Signed tags
-  # git fetch -t git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.33.y.git
+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.
-And just diff it:
+  # git tag -u kang@rsbac.org -s my_tag_name
-  # git diff v2.6.33.2
-Or diff with a RSBAC tag (to create a patch for one kernel version):
+=== The cheat sheet (this is where you find all common commands) ===
-  # git diff v2.6.33.2 v2.6.33.2-rsbac-1.4.4
+Taken from: http://git.wiki.kernel.org/index.php/GitCheatSheet
-  * Make a tag (from current branch/checkout)
+{{documentation:dev:scm:git-cheat-sheet-medium.png|}}
-  # git tag -a my_tag_name
-  * Signed tags
+=== Ease up your tasks ===
-git is a bit stupid about tag signing. Yeah, really.
+Use a GUI log browser!
-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.
+For example: gitk or gitg, but there are many others.
-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
+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/
+==== Archived information ====
+//This method should in theory never be needed anymore. However, the information is kept in case anything really wrong happens.//
-=== Recover the repository after a non-RSBAC commit ===
+** 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).

//