From the top directory of your local repository (that is, the directory which contains the <tt>.git</tt> subdirectory) run the following command:

From the top directory of your local repository (that is, the directory which contains the <tt>.git</tt> subdirectory) run the following command:

−

git pull http://www.linux-mips.org/pub/scm/linux.git

−

−

or alternatively if you want to use the git protocol:

git pull git://ftp.linux-mips.org/pub/scm/linux.git

git pull git://ftp.linux-mips.org/pub/scm/linux.git

−

While the git protocol is more effective it is using port 9418 which [[Wikipedia:Paranoia|paranoid]] firewall admins may have blocked, so there is http as fallback.

+

=== Which git protocol to use ===

+

Generally these days the git protocol (the <tt>git://</tt>) 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 <tt>git pull</tt>.

+

* 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 <tt>git pull</tt>. Another issue with the git protocol is it's use of TCP port 9418 which [[Wikipedia:Paranoia|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 [[Wikipedia:Fascist|fascist]] firewall admins.

== Status of CVS to GIT conversion ==

== Status of CVS to GIT conversion ==

Revision as of 11:53, 25 January 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. However git is currently being experimented with and it is expected to eventually replace CVS for at least all kernel work.

GIT's rapid development has meant there is little high-level documentation, so here's a local page on WhatIsGit.

Accessing GIT repositories

The GIT repositories can be accessed by rsync://ftp.linux-mips.org/git 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 rsync://ftp.linux-mips.org/git/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 no 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 too a lesser degree the linux-2.4 branch.

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 checkout the HEAD of a branch, tags are unfortunately not supported. But first, this is how to list the available tags:

Git pull and tags

Git considers tags something local. That means git clone will replicate all the tags but git pull will not pull new tags. 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 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.