i-scream Git Repositories

The i-scream Git repositories contain the currently developed source code. All historic source code can be found in CVS.

All code available in the Git repositories is licensed under the GPL unless otherwise stated.

Web Access

We use GitWeb to provide a visual frontend to the Git repositories. It allows you to browse around each repository, viewing any version of a file, and the differences between different versions. There is also a link to download the latest version of any section.

http://git.i-scream.org/

Anonymous Git Access (read-only)

Anyone can access the i-scream Git repositories in anonymous read-only mode. The following commands will both allow you to check out the libstatgrab repository. To see what other repositories are available you can look at the web frontend. Choose whichever protocol you prefer. 

git clone http://git.i-scream.org/libstatgrab
git clone git://git.i-scream.org/libstatgrab

Developer CVS Access (write)

The i-scream development team have write access to the required Git repositories. This is only available over SSH on a non-standard port. You will need to have a SSH key installed on the server first. Then just clone and push using ssh. 

git clone ssh://git@git.i-scream.org/libstatgrab

GitHub Mirror

Our Git repositories are mirrored on GitHub. The master repository that we'll push commits to is located here, but we provide the GitHub mirrors to make it easier for you to make changes and work with our code.

http://github.com/i-scream

Git guidelines

We've chosen a set of guidelines to work by so that everybody is clear about how the Git repositories will be used. This should make life easier for developers and users. The aim is to keep things clear and simple without adding unnecessary overheads. We don't have need for anything as complex as git-flow.

  1. The master branch will always be buildable and should be usable. Development work does not happen here directly.
  2. New releases will be taken from the master branch and will be tagged there.
  3. The master branch will never have its history rewritten.
  4. Development work will be done on branches. These branches may only live for the period of the development work. Once the work is complete and tested it will be merged to master and the branch may be deleted.
  5. The history on development branches may be rewritten to tidy things up before merging. This probably won't happen often, but don't get upset if it does.
  6. If you want to submit changes it's best to do them against the master branch unless you're specifically working with a developer on an issue already.
  7. Gratuitous merge commits should be avoided, particularly when merging development branches to master. They don't offer much in the way of useful information and make operations like bisect harder. In particular, if you pull changes to your local repository and end up with a merge commit you should use rebase to get rid of it before pushing.