From LinuxHam
Jump to: navigation, search

::We will hereby start scouring the net for people who say git is hard to
understand and use, and just kill them. They clearly are just polluting
the gene pool.

All right, we're not quite that bad. Yet. These days the Linux world has largely switched to GIT as its 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. has used CVS since 2001 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.

Accessing GIT repositories

The GIT repositories can be accessed by git:// The http and rsync protocols are also supported but not recommended. Here are two example commands using the libax25.git repository; you can substitute the name of another repository (see further below) for libax25.git in the examples.

Cloning a repository

   git clone git://

This will create a new directory under the current working directory called linux. To use a different name specify it on the command line as an additional argument and it will become the target. Here is an alternate form of the command which creates a local directory called libax25.git instead of libax25.

   git clone git:// linux.git

Updating a repository

When the repository was cloned the upstream URL was saved into the file .git/remotes/origin. This is the default location for git to pull updates. If you wish to modify the default URL you may edit that file directly.

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

   git pull

This will pull updates from the repository and merge them into your local repository.

It is also possible to specify an alternate URL by specifying it on the command line.

   git pull git://

Typing in URLs can be tedious. You may create shortcuts to repeatedly used URLs by saving them in a remotes file. Alternate URLs may be saved in the .git/remotes/REMOTENAME file where the REMOTENAME string is the name that you wish to call that source location. Let's say that that you wanted to clone this long URL git:// but find that a lot to type repeatedly. If that is specified in a remotes file linus then the following command would pull from it. git pull linus

Which git protocol to use

Generally these days the git protocol (the git://) URLs) is the prefered protocol.

  • git Git's own protocol which tries to heavily optimize the amount of bandwidth used and thus is generally very efficient for updates. An issue with the git protocol is its 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.
  • https More secure than http but otherwise pretty much the same thing. uses SSL certificates from and CACERT's root certificate is not included with most operating systems. A notable exception is Debian however. So if attempts to access a repository via https fail with an error message about an invalid SSL certificate, you can:
    • use one of the other protocols listed in this section
    • disable the verification of the SSL certificate. On a UNIX or Linux type of system you do this by setting the GIT_SSL_NO_VERIFY variable, for example: GIT_SSL_NO_VERIFY=yes git clone Note that this disables the verification of the certificate thus leaving you vulnerable to the same attacks as plain http.
    • manually import the root certificate. The preferable but also most complicated approach.
  • rsync The oldest git protocol, deprecated and supposed to eventually go away. Suffers from a low probability race condition. Its advantage is the lowest CPU usage on the server side. Also some firewalls that don't allow git git protocol will allow rsync. Not recommended for pulling or fetching. Heck, it really should be considered the last alternative. Rsync is not what in git parlance is called an intelligent transport which means that all new pack files on the server side will be transfered to the client even if only a single object from the pack would need to be transfered.

Status of CVS to GIT conversion

All development has been moved to git. For the time being the CVS Server is still running to maintain the history and help users with existing CVS checkouts however there will be no more CVS checkins.

It has been attempted to convert the entire history of CVS with some of the details that CVS doesn't record manually restructed and the tarball history which predates the CVS history. Various generated files, even some binaries were checked into the CVS history and often these files were deleted or regenerated for the distributed archives, so there is no 100% equivalence between the tagged versions and corresponding tarballs.

Checking out a tagged release with git

This is how to list the available tags:

[ralf@dea linux-git]$ git tag -l
$ git tag -l

The actual list of tags is longer. Okay, so let's assume we want to checkout the libax25-0.0.11 release:

[ralf@dea linux-git]$ git checkout -b my-0.0.11 libax25-0.0.11

What this exactly does is creating a new branch named my-0.0.11 at linux-0.0.11 and checking out it's HEAD.


Gitweb allows simple browsing of git repositories in a web browser. Git web is available at

See also