Difference between revisions of "Git"
(→Size issues with the kernel repository)
(The git protocol is now performant so remove the rsync stuff)
|Line 8:||Line 8:|
=== Cloning a repository ===
=== Cloning a repository ===
git clone ://ftp.linux-mips.org/pub/scm/linux.git linux.git
=== Updating a repository ===
=== Updating a repository ===
Revision as of 18:46, 1 March 2006
These days the Linux world has largely switched to GIT as it's SCM. Git is a fairly low-level thing, more the backing store of an SCM - or plumbing in Linus's words - than a full-blown SCM but it's growing up very quickly. Linux-mips.org has used CVS since 1997 and so naturally is a little more conservative in switching to a new tools as we don't want to drop all the history that's hidden in these trees.
GIT's rapid development has meant there is little high-level documentation, so here's a local page on WhatIsGit.
- 1 Accessing GIT repositories
- 2 Status of CVS to GIT conversion
- 3 A note on branches in the kernel repository linux.git
- 4 Branches in the linux-malta.git repository
- 5 Checking out a tagged release with git
- 6 Git pull and tags
- 7 Tags converted from the kernel CVS tree
- 8 Shallow kernel repository
- 9 Disk space requirements for the kernel repository
- 10 Gitweb
- 11 External links
Accessing GIT repositories
The GIT repositories can be accessed by rsync://ftp.linux-mips.org/pub/scm or via http://www.linux-mips.org/pub/scm/. The rsync protocol is recommended for initial cloning of repositories while for later
git fetch or
git pull via http or the git protocol is preferable. Here are two example commands using the linux.git repository; you can substitute the name of another repository (see further below) for linux.git in the examples.
Cloning a repository
git clone git://ftp.linux-mips.org/pub/scm/linux.git linux.git
Updating a repository
From the top directory of your local repository (that is, the directory which contains the .git subdirectory) run the following command:
Which git protocol to use
Generally these days the git protocol (the git://) URLs) is the prefered protocol, says the git documentation. The practical experience on linux-mips.org shows this isn't quite true, so here a quick discussion on when to use which protocol. So for most people this just means use the rsync protocoll for initial cloning, then update using the git protocol for updates.
- rsync The oldest git protocol, deprecated and supposed to eventually go away. Suffers from a low probability race condition. It's advantage is the lowest CPU usage on the server side. Due to it's efficiency it is the prefered protocol to use for initial cloning. Not recommended for git pull.
- git Git's own protocol which tries to heavily optimize the amount of bandwidth used and thus is generally very efficient for updates. With large git trees like linux-mips.org's it has been found to be a massive user of CPU time on the server side for cloning (update generally is ok), so it is urgently requested to prefer rsync for the initial cloning of a repository, then use the git protocol for subsequent updates with git pull. Another issue with the git protocol is it's use of TCP port 9418 which paranoid firewall admins may have blocked.
- http Rather inefficient usage of bandwith and CPU but since http is generally enabled in firewalls it exists for those poor souls suffering from fascist firewall admins.
Status of CVS to GIT conversion
At this time linux.git and linux-malta.git trees are in active use. The MaltaRef_2_6 branch on linux-malta.git is a stable, tested kernel recommended for the Mips Malta. For the time being arcboot is still being maintained via CVS; all other archives are only historical.
A note on branches in the kernel repository linux.git
Following the recent changes in the Linux development model merges with Linus are now happening much more frequently and the difference between the git archives of Linus and linux-mips.org has become much smaller and is expected to shrink further. One side effect of this is that the heads of the branches will now pick up any kind of problem much faster than it used to be in the past. It therefore is suggested to people that don't want to fight bugs on this front to only use the tagged releases. This affects primarily the master branch on which the active 2.6 development is happening and to a lesser degree the linux-2.4 branch.
Branches in the linux-malta.git repository
The linux-malta.git repository is a superset of linux.git with the addition of two stable branches MaltaRef_2_6 and MaltaRef_2_4. To use one of these stable branches after cloning the repository:
[ralf@dea linux-malta-git]$ git-checkout MaltaRef_2_6
Checking out a tagged release with git
Bare git doesn't make this as easy as you'd like it to. So while git-checkout does support checking out the HEAD of a branch, tags are unfortunately not supported. But first, this is how to list the available tags:
[ralf@dea linux-git]$ ls .git/refs/tags linux-1.1.68 linux-2.4.11 linux-2.5.53 [...] linux-2.4.10 linux-2.6.14-rc1 linux-2.6.14 [ralf@dea linux-git]$
The actual list of tags is much longer. Okay, so let's assume we want to checkout the linux-2.6.14 release:
[ralf@dea linux-git]$ git reset --hard $(cat .git/refs/tags/linux-2.6.14)
This should only take a few seconds.
Git considers tags something local. That means git clone will replicate all the tags but git pull will not pull new tags. Git 1.1 fixes this. Git-push however can be convinced to push tags by either explicitly listing them on the command line or the --all option.
Tags converted from the kernel CVS tree
When converting the kernel CVS repository to git the tags were recreated by a script, not through conversion. As such it is possible that the CVS tag and it's equivalent git tag refer to slightly different versions; we haven't verified that. Also, CVS didn't allow the "." character to be part of a tag name, so CVS tags used to look like linux_2_6_12 - counterintuitive. Git doesn't have such restrictions and so the tags name has become linux-2.6.12.
Shallow kernel repository
The kernel repository is about 312MB. This is the entire history of the Linux/MIPS project as far as still available dating back all the way to 1994, arguably quite a bit too much for most uses. So there is now a second stripped down repository starting at 2.6.15. It can be cloned with
git clone git://ftp.linux-mips.org/pub/scm/linux-2.6.15.git linux.git
Disk space requirements for the kernel repository
As of this writing the size is approximately 63MB compared to 312MB for the full repository and the size saving of the shallow repository - obviously - comes at the price of the history before 2.6.15. Other than that the tree is identical to the main git kernel repository. Additional 275MB are needed for checking out the repository plus another upto 85MB for building - even more for very large configurations, debugging etc.
Using aggressive compression settings (see git-pack-objects manpage) on the order of 70MB can be saved for the full repository at the price of somewhat lower performance. Linux-mips.org stopped doing so as it puts an inacceptable burden on the aging server machine.
Gitweb allows simple browsing of git repositories in a web browser. Git web is available at http://www.linux-mips.org/git.