- -

- 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. -

- The master branch will always be buildable - and should be usable. Development work does not happen - here directly. -
- New releases will be taken from the master - branch and will be tagged there. -
- The master branch will never have its history rewritten. -
- 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. -
- 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. -
- 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. -
- 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. -

- -