CMake/Git

CMake version tracking and development is moving to Git.

Experimental Repository

We have published an experimental repository on cmake.org. WE REQUEST THAT NO ONE PUBLISH A CLONE OF THIS REPOSITORY AT AN ONLINE HOSTING SITE. This may or may not be the final version of history after conversion from CVS. It may be removed or rewritten at any time. We prefer to not have multiple incompatible histories out there. The final conversion will be available soon, at which point we may all begin sharing changes!

At the time of this writing it has only the development mainline and no branches or tags. These will be converted and added later without hindering the main move.

One may clone the repository using git clone through the native git protocol:

$ git clone git://cmake.org/cmake-tmp.git CMake

or through the (less efficient) http protocol:

$ git clone http://cmake.org/cmake-tmp.git CMake

The repository is also available by anonymous cvs pserver, served by git cvsserver. The server maps git branches to cvs modules, so one must ask cvs to get the module "master":

$ cvs -d :pserver:anonymous@cmake.org:/cmake-tmp.git co -d CMake master

One may browse the repository online using the Gitweb interface at http://cmake.org/gitweb.

Development

We provide here a brief introduction to development with Git. See the Resources below for further information.

First, use git config to introduce yourself to Git:

$ git config --global user.name "Your Name"
$ git config --global user.email "you@yourdomain.com"

Optionally enable color output from Git commands:

$ git config --global color.ui auto

The --global option stores the configuration settings in ~/.gitconfig in your home directory so that they apply to all repositories.

Committing

After cloning the repository using the above instructions one may commit new changes locally. Git creates commits based on a stage (also called index or cache) that sits between the work tree and the repository. After editing a file, say Modules/readme.txt, use git status to see the state of the stage and work tree:

$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Modules/readme.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

This tells you that no changes are staged for commit (i.e. the stage and HEAD commit have identical content), and that the Modules/readme.txt file in the work tree has been modified from what is in the stage. We stage the change using git add:

$ git add Modules/readme.txt

and check the status again:

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   Modules/readme.txt
#

This tells you that changes have been staged for commit, and that the work tree is identical to the stage. Now use git commit to create a commit:

$ git commit

Git will bring up an editor interactively to ask for the commit message. The editor will already have the output of git status in it as a reminder, but the comment lines will be removed from the message automatically. A good convention is to use a short one-line summary (preferably 50 characters or less), then a blank line, then a detailed description:

Clarify documentation of module conventions

The previous description of output variable XXX_YYY_ZZZ was not precise.
We clarify the wording and give an example.

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
# Changes to be committed:
#   (use "git reset HEAD^1 <file>..." to unstage)
#
#       modified:   Modules/readme.txt
#

Upon exit it will create the commit (unless you leave the message blank to abort the commit). After committing, check the status again:

$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)

This tells you that the (new) HEAD commit, stage, and work tree are all identical. Furthermore it says that your local master has a commit on top of what was last fetched from origin.

Publishing

The experimental repository is unofficial and changes published in it are not considered part of the project. However, developers may experiment with publishing work as follows.

Git automatically configures a new clone to refer to its origin through a remote called origin. Initially one may fetch or pull changes from origin, but may not push changes to it.

In order to publish new commits in the cmake.org repository, developers must configure a push URL for the origin. Use git config to specify an ssh-protocol URL:

$ git config remote.origin.pushurl git@cmake.org:cmake-tmp.git

All publishers share the git@cmake.org account but each uses a unique ssh key for authentication. To request access, fill out the Kitware Password form. Include your ssh public key and a reference to someone our administrators may contact to verify your privileges.

Note that we may not grant all contributors push access to the cmake.org repository. The distributed nature of Git allows contributors to retain authorship credit even if they do not publish changes directly. After the final conversion to Git is finished we will consider pull requests from online Git hosting sites.

Once your push URL is configured and your key is installed for git@cmake.org then you can try pushing changes. Continuing from the above commit example, you have one commit on your local master than what was last fetched from origin. Use git push to send the changes back to origin:

$ git push

This section is unfinished...

Resources

Additional information about Git may be obtained at these sites:

• Git Homepage
• Git Community Book
• Everyday Git
• Git Cheat-Sheet
• Pro Git