Using GIT at Savannah

URL-s summary:

  • git:// - git lightweight protocol (read-only access)
  • ssh:// - developer access using SSH
  • - slow dumb protocol, http-based, for use behind fascist firewalls

Web browser:

If you use ssh-based access, please verify the host keys first at SshAccess ( is the same host as

Note: there is at most a 1/2h delay between Git activation in the web front-end, and its creation on the system.

Basic commands

  • Checkout:

    git clone git://
  • Firewall checkout: if you're behind a outgoing-traffic-filtering firewall, you can use Git's "dumb protocol" via HTTP - note that this is SLOWER, both for you and Savannah. Avoid if possible, and please tell your local sysadmin to allow outgoing git traffic (port 9418):

    git clone

    Note: we enabled git-http-backend (a CGI script) to speed up HTTP cloning, but this is still not the recommended protocol.

  • Project member checkout: if you want to be able to push your changes back into the repository on savannah:

    git clone

Developer setup

(For git 1.5.1 or newer)

Your identity for when you push commits (strongly recommended):

git config --global "Your Name Comes Here"
git config --global

Enable colors (optional):

git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto

Disabling colors [defaults on in later git versions] (optional):

git config --global color.ui false

Developer basic commands

  • Create the initial directory and change to it:

    mkdir project_directory
    cd project_directory
  • Initial push / import:

    git init
    touch README
    # edit/add other files...
    # Import everything:
    git add .
    git commit -m "Initial import"
    #  initial publication to the 'master' branch
    git push --all

    Note: at this point your repository is not setup to merge _from_ the remote branch when you type 'git pull'. You can either freshly 'clone' the repository (see "Developer checkout" below), or configure your current repository this way:

    git remote add -f origin
    git config branch.master.remote origin
    git config branch.master.merge refs/heads/master
  • Developer checkout (via SSH - beware of punctuation):

    git clone ssh://
    # or
    git clone
  • Commit:

    cd project/
    # <edit some_existing_file>
    git commit -a -m "I automatically commit modified files"
    # <edit some_other_existing_file and something_else>
    git add some_other_existing_file
    git commit -m "I only marked some_other_existing_file for commit"
    # Check your changes with the graphical tool
    # Send everything to Savannah
    git push

Fixing checkout from git:// to ssh://

If by mistake a developer has checked out a repository using the public anonymous read-only git:// url this can be changed to the authenticated ssh:// url using git remote set-url:

git remote set-url origin ssh://

If the origin remote has been removed, or if someone wishes to remove origin and recreate it, then it may be removed and set:

git remote rm origin
git remote add origin ssh://
git fetch
git branch -u origin/master master

Shallow checkouts

When bandwidth is an issue, people can download the latest version of your repository without downloading all the history, using "shallow checkouts". Note that such a copy has limitations, see, option --depth for details.


$ git clone --depth 1 git://
Initialized empty Git repository in /tmp/gnulib/.git/
remote: Counting objects: 9897, done.
remote: Compressing objects: 100% (5462/5462), done.
Indexing 9897 objects...
remote: Total 9897 (delta 7382), reused 5737 (delta 4419)
 100% (9897/9897) done
Resolving 7382 deltas...
 100% (7382/7382) done

$ du -sh gnulib/.git
6,3M   gnulib/.git

$ du -sh full-gnulib/.git
28M    full-gnulib/.git

git-cvsserver pserver compatibility

You can download a git repository using the CVS client, thanks to a pserver-compatible server from git:

$ cvs co -d autoconf master
cvs checkout: Updating autoconf
U autoconf/.cvsignore
U autoconf/.gitattributes
U autoconf/.gitignore
U autoconf/.x-sc_prohibit_atoi_atof
U autoconf/.x-sc_space_tab
U autoconf/.x-sc_sun_os_names
U autoconf/.x-sc_trailing_blank
U autoconf/.x-sc_useless_cpp_parens
U autoconf/AUTHORS
U autoconf/BUGS
U autoconf/COPYING

Importing from CVS

Git comes with the tool, git-cvsimport which will import a CVS repository into a new git project. You may want to use this for converting your existing CVS repository to a new git repository.

We will use a file which maps a savannah login name username to real name (option -A) in the git-cvsimport command. The format of this file like this:

rms = Richard M. Stallman <>
toto = Another User <>

After creating this file, run something along the lines of the following mythical shell session:

$ # create authors.txt
$ project='myproject' # change myproject
$ myrepository='' # Or whatever you usually use for CVS
$ mkdir $project
$ cd $project       # Note: that this is new directory. It is not git yet.
$ module='mymodule'   # adjust this
$ git-cvsimport -A ../authors.txt -p x -v -d:${myrepository}:/sources/$project $module

Adjust the variables myrepostory to be whatever you use to checkout CVS; the address won't be correct if your project is a GNU project. If your project is old or has lots of commits, git-cvsimport may take a long time because it is replaying the entire commit history: copying down each version of each file and then performing essentially git-commit for every CVS commit.

Importing from SVN

Git comes with 2 SVN-related tools: git-svnimport and git-svn. git-svnimport is for importing revisions (a one-shot import, or incrementally); git-svn is a 2-way gateway to a SVN repository, similar to SVK, more useful for maintaining a local branch than for importing a repository (IMHO). We'll use git-svnimport.

We will use a file which maps a savannah login name username to real name (option -A). It looks like this:

rms = Richard M. Stallman <>
toto = Another User <>

Common invocation:

git-svnimport -v -I .gitignore -A ../authors.txt file:///home/me/svn_repo

To ignore branches:

git-svnimport -v -I .gitignore -A ../authors.txt -b idontexist file:///home/me/svn_repo

git-svnimport assumes there is a trunk, a branches, and a tags directory (names are configurable) and ignores other directories. You may run into troubles if your layout changed during your former SVN life.

You'll usually perform the import several times before getting what you want. For this reason it's preferable to rsync the SVN repository locally, or create it from a dump:

rsync -av rsync:// svn_repo

svnadmin init svn_repo
zcat myproject.dump.gz | svnadmin load svn_repo/

Importing from GNU Arch

Use git-archimport.

Example importing a project with a project--main--1.0 main archive and a project--release--1.7 tag, converting the Arch-style names into Git-style names:

git-archimport me@domain.tld--2007/project--main--1.0:master project--release--1.7:v1.7

Importing from CVS

First thing you may want to do is to tag the state of your CVS repository and declare it as closed. For example:

$ cd my-checked-out-cvs-repository
$ cvs tag cvs-repository-moved-to-git

On your project page, activate git. For example the libcdio project the URL for the project page is:

"activated" is in the second column and the "git" row is midway down the page. If you forget to do this or git is not active, you may get a message like this:

Pushing to
fatal: '/srv/git/libcdio.git': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly

After this done create a local git repository on your computer, using the instructions under Importing from CVS. This will take a while and it will create a local git repository with at least two branches:

$ git show-branch -a
* [master] Moved from CVS to GIT.
 ! [origin] Moved from CVS to GIT.
*+ [master] Moved from CVS to GIT.

Before pushing this to your savannah project page you might want to rename or remove that "origin" branch. It has the same state and history as the master branch so you won't lose any information. (Footnote: Normally the origin branch is used by developers who prefer to use git while working on projects that only run a central CVS repository. They do their work on "master" but track the changes in the CVS repository in the "origin" branch.) This is not what you are going to do anyway and unfortunately "origin" is also the default alias name for remote git repositories and thus it may lead to unnecessary confusion. You can remove the branch like this:

$ git branch -d origin

Don't worry! If you ever need to recreate that branch you can always do so by branching off at that last CVS commit and call the branch "origin", "cvs" or "back-in-the-dark-ages".

Now you are ready to push this git repository to your savannah project page using the instructions under Pushing a Newly-Created, Existing, or Converted Git Repository.

If you have converted from a different version control repository to git then consider disabling commits to the previous location so as to prevent confusing history creation.

Pushing a Newly-Created, Existing, or Converted Git Repository

If you are importing a repository with tags, e.g. for past releases, use the --tags option to send them with the initial import:

$ login='mylogin'
$ project='myproject'
$ git push --tags -v ${login}${project}.git

Similarly remember to use the '--all' flags to push all branches, not just the 'master' one:

$ git push --all -v ${login}${project}.git

If you have branches and you don't push all branches when you do a git-clone you may get error messages like the one below:

$ git clone git://
Initialized empty Git repository in /src/external-vcs/libcdio/.git/
remote: Counting objects: 15471, done.
remote: Compressing objects: 100% (3223/3223), done.
Receiving objects: 100% (15471/15471), 16.56 MiB | 231 KiB/s, done.
Resolving deltas:  99% (12089/12208)   Resolving deltas: 100% (12208/12208)   Resolving deltas: 100% (12208/12208), done.
cd: 491: can't cd to /src/external-vcs/libcdio/.git/refs/remotes/origin
Warning: Remote HEAD refers to nonexistent ref, unable to checkout.

Removing a branch

We don't really like this, but there's a way to remove remote branches. We don't like it because this allow project members to potentially remove free software from Savannah, willingly or by mistake. This is mitigated by the fact it is very easy to push back changes.

When removing a branch, only its reference is removed, and the commit are still reachable by their identifiers. However, Savannah may prune unreachable commits (git gc), so don't count on this.

To remove a branch:

git push origin :mybranch

For an easier syntax, you can use git-publish-branch -d (

Non-Fast-Forward commits

'non-fast-forward' commits are commits which result in rewriting the commit history, leading to lost commits (see for a technical explanation).

In Savannah, non-fast-forward commits are disallowed, for the same reason that RemovingProject is disallowed: to prevent removal of published code. Another reason to avoid non-fast-forward commits is to prevent troubles for users who already cloned a public repository - as a simple 'pull' will fail in their local repository.

Under special circumstances, savannah administrators can temporarily enable non-fast-forward commits in a specific repository. Such cases include:

These are done on a case-by-case basis, and enabled only for a short period (usually 24 hours). Please submit a support request ( or email if you need to temporarily enable non-fast-forward commits.

An advanced configuration option where non-fast-forward commits are enabled for all branches except the master branch as been discusssed but is not currently implemented (see



  • How does a project admin update the "description" file for the web interface?

    Unfortunately nothing has been implemented to allow the project administrator to do this from the web interface. Fortunately this doesn't need to change very often. Please submit a support request and a Savannah Admin will happily make the changes for you.

  • Similarly, how can a project admin update the "HEAD" file to point to another branch?

    Unusual branching strategies are strongly discouraged. "Standard is better than better." You are encouraged to use typical branching strategies. If you need something custom for your project please file a support request and a Savannah Admin will discuss this with you and take any actions that are needed.