Gromacs

Git

    Gromacs now uses Git for source code control. There were many reasons for the move from CVS, but the strongest point for Git is that it has much better support for truly distributed source code management - anybody can set up their own repository and allow others to pull code from it. In contrast to CVS you always have the full history available on your own computer, anybody can have their own branches and it is significantly easier to create patch sets between branches. More information about Git is avaiable e.g. on its Wikipedia page. 

    Checking out the Gromacs source code using git

    Command line
    git clone git://git.gromacs.org/gromacs.git
    Web interface

    The git repository can be also accessed through the web interface at http://repo.or.cz/w/gromacs.git or with the Redimine repository browser.


    It has some nice features:

    • html interface to look at the changes without actually pulling them
    • graphical branch merging graph (like gitk --all)
    • download the latest snapshot as a tarball without git
    • RSS feed of the latest commits
    • search the history for changes without git
    • create an unofficial fork which is linked to the main repository and so easy to find
    • git pull from http, for those who are behind a proxy (hello@mpip)
    • synced once an hour

    Find more about other available repositories in the Basic Git Usage guide.

    Moving from CVS to Git, anonymous access

    For technical reasons, we have chosen to make the move as a clean cut rather than trying to support both CVS and Git in parallel. If you only used CVS for read-only access to get the latest code this is a non-issue, just check out using Git instead!

    Moving from CVS to Git, developers with modified code

    We will keep the CVS server live (but in read-only mode!) for a little while, but with the version frozen to the date of the move (June 3, 2009). If you still have lots of non committed code, do a "cvs diff" to create a patch against the last version of CVS, check out a new Git-based tree, and finally apply the patches there. This might lead to some conflicts, but in return it will be much smoother for you to track the main tree in the future. 

    Page last modified 18:44, 12 Apr 2012 by pszilard