ITK/Git

ITK version tracking and development is hosted by Git.

Official Repository

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

Cloning

These instructions assume a command prompt is available with git in the path. See our Git download instructions for help installing Git.

Clone ITK using the command

$ git clone git://itk.org/ITK.git

If your institution's firewall blocks the Git port for outgoing connections you may see an error similar to:

Initialized empty Git repository in C:/abc/ITK/.git/itk.org[0: 66.194.253.19]:
errno=No such file or directory
fatal: unable to connect a socket (No such file or directory)

In that case, see below.

If you want to run tests, add the --recursive option to download the Testing/Data submodule.

$ git clone --recursive git://itk.org/ITK.git

This requires Git 1.6.5 or higher. If you do not have it, see below.

All further commands work inside the local copy of the repository created by the clone:

$ cd ITK

If you already cloned and want to add the Testing/Data submodule then run

$ git submodule update --init

For ITKApps, use the url

git://itk.org/ITKApps.git

instead.

Updating

If you have made no local commits and simply want to update your clone with the latest changes, run

$ git pull
$ git submodule update

If you know you do not have the Testing/Data submodule checked out then you can skip the submodule update command.

Branches

At the time of this writing the repository has the following branches:

• master: Development (default)
• release: Release maintenance
• nightly-master: Follows master, updated at 01:00 UTC
• hooks: Local commit hooks (place in .git/hooks)
• dashboard: Dashboard script (see below)

Release branches converted from CVS have been artificially merged into master. Actual releases have tags named by the release version number.

After cloning your local repository will be configured to follow the upstream master branch by default. One may create a local branch to track another upstream branch using git checkout:

$ git checkout -b release origin/release

As a shortcut with Git >= 1.6.5 one may choose a branch during the initial clone:

$ git clone -b release git://itk.org/ITK.git ITKRel

Development

ITK development uses a branchy workflow based on topic branches. Currently we use a single master integration branch for development and one release branch for release maintenance.

Workflow

Our collaboration workflow consists of three main steps:

1. Create Topics: Develop Locally
2. Share Topics: Code Review with Gerrit
3. Integrate Topics: Merge using Topic Stage

Local Development

We provide here a brief introduction to local ITK development with Git. See the Resources page for further information such as Git tutorials.

Introduction

These steps are a one-time setup per-user per-machine.

We require all commits in ITK to record valid author/committer name and email information. Use git config to introduce yourself to Git:

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

Note that "Your Name" is your real name (e.g. "John Doe", not "jdoe"). While you're at it, optionally enable color output from Git commands:

$ git config --global color.ui auto

If less displays strange characters and no color, your LESS environment variable may already be set. You can override the less options with:

$ git config --global core.pager "less -FXRS"

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

Local Clone

Create a local clone of the repository to get a work tree for local development. See instructions above.

Hooks

This step should be done once for each local clone of the ITK repository. If you forget this step instructions will be printed on the first attempt to "git commit".

The hooks branch provides local commit hooks to be placed in .git/hooks. It is shared by many public.kitware.com repositories. See the general hooks information page for details.

Code Review

We use Gerrit Code Review to perform online code reviews. See these pages for details:

• ITK/Gerrit
• ITK/Gerrit/Primer

Once a change is reviewed and approved in Gerrit, an ITK developer with access to the upstream repository must integrate the change using the ITK Topic Stage, covered next.

Topic Stage

We provide a "ITK Topic Stage" repository to which developers may publish arbitrary topic branches and request automatic merges.

The topic stage URLs are

• git://itk.org/stage/ITK.git (clone, fetch)
• http://itk.org/stage/ITK.git (clone, fetch, gitweb)
• git@itk.org:stage/ITK.git (push)

See our Topic Stage Workflow documentation for general instructions. (Currently ITK does not have a next branch. Just skip that part of the instructions and merge directly to master.) When accessing the ITK stage, one may optionally substitute "ssh git@itk.org stage ITK ..." for "ssh git@public.kitware.com stage <repo> ..." in the ssh command-line interface.

Stage Usage Summary
Initial Setup:	$ git remote add stage git://itk.org/stage/ITK.git $ git config remote.stage.pushurl git@itk.org:stage/ITK.git
Fetch Staged Topics:	$ git fetch stage --prune
Create Local Topic:	$ git checkout -b topic-name origin/master $ edit files $ git commit
Stage Current Topic:	$ git push stage HEAD
Print Staged Topics:	$ ssh git@itk.org stage ITK print
Merge Staged Topic:	$ ssh git@itk.org stage ITK merge topic-name

Note that the stage implementation is not ITK-specific and is used for other projects too. If the merge attempt conflicts it may print instructions for performing the merge manually. Ignore these instructions; you will not be able to push the merge commit directly. Instead, identify the commit that conflicts with yours, merge it into your topic locally, push the topic to the stage again, and then repeat the merge request.

Publishing

Pushing

Authorized developers may publish work directly to itk.org/ITK.git using Git's SSH protocol. To request access, fill out the Kitware Password form.

See the push instructions for details.

For ITK, configure the push URL:

git config remote.origin.pushurl git@itk.org:ITK.git

For ITKApps, configure the push URL:

git config remote.origin.pushurl git@itk.org:ITKApps.git

Update Hook

The itk.org repository has an update hook. When someone tries to push changes to the repository it checks the commits as documented here.

Patches

Contributions of bug fixes and features are commonly produced by the community. Patches are a convenient method for managing such contributions.

One may send patches to one of our mailing lists:

• ITK Users Mailing List
• ITK Developers Mailing List

See our patch instructions for details.

Submodules

In the ITK.git repository, Testing/Data is not really a directory. It is a submodule, meaning that its content does not actually appear in ITK.git, but in the ITKData.git repository. In ITK.git Git stores in the Testing directory an entry called "Data" that refers to a commit from the ITKData repository. Indeed, one can see this using a low-level "git ls-tree" command:

$ git ls-tree -r 9ec7c03d -- Testing/Data
160000 commit bc9550f3215104818f0464fd6ede7c8ea3462aeb  Testing/Data
              ^^^^^^^^

We can view this commit from ITKData.git: http://itk.org/gitweb?p=ITKData.git;a=commitdiff;h=bc9550f3.

This approach allows us to keep the bulky data out of the main repository and version it separately. Every version of ITK throughout history refers to the exact version of ITKData that it needs using this submodule link.

Updating Data

One can think of the Testing/Data entry in ITK's tree kind of like a file that tells Git which version of ITKData.git we want. If we want to change the version of ITKData.git to which we refer from ITK (perhaps because we've created a new commit in ITKData with some updated images), we commit a change to ITK that updates the Testing/Data "file" to refer to the new version.

First, make the changes to ITK needed to use the new data correctly:

$ git checkout -b my-new-test origin/master
$ git submodule update
$ edit files

Then, make the change to Testing/Data and publish it:

$ cd Testing/Data
$ git checkout master
$ git pull --rebase origin master
$ edit data-files
$ git add -- data-files
$ git commit
$ git config remote.origin.pushurl git@itk.org:ITKData.git
$ git push origin master
$ cd ../..

Finally, update ITK to reference the new version of ITKData. Our work tree already has the new version checked out in Testing/Data so we just need to tell Git to include this change in the next commit.

$ git add -- Testing/Data

The commit may also include the files edited above to use the new data:

$ git add -- files
$ git commit

Now publish the ITK commits as you would any other topic.

Testing

Dashboard

The dashboard branch contains a dashboard client helper script. Use these commands to track it:

$ mkdir -p ~/Dashboards/ITKScripts
$ cd ~/Dashboards/ITKScripts
$ git init
$ git remote add -t dashboard origin git://itk.org/ITK.git
$ git pull origin

The itk_common.cmake script contains setup instructions in its top comments. Update the dashboard branch to get the latest version of this script by simply running

$ git pull origin

Troubleshooting

Firewall Blocks Port 9418

Some institutions have firewalls that block Git's native protocol port 9418. Use the "url.<base>.insteadOf" configuration option to map git URLs to http:

$ git config --global url.http://itk.org/.insteadOf git://itk.org/

This tells Git to translate URLs under the hood by replacing prefixes. After running these commands once in your home directory then you can just use the "git://" mentioned elsewhere on this page and git will use the http protocol automagically.

Git Below 1.6.5

To clone ITK using Git 1.6.4 or lower, use the commands

$ git clone git://itk.org/ITK.git
$ cd ITK
$ git submodule init
$ git submodule update

The remote end hung up unexpectedly

If git push fails with

fatal: The remote end hung up unexpectedly

check that you set the pushurl with "git config". See the push instructions.

If you suspect your ssh key may not be configured correctly, see the authentication test instructions.

Tips

Tip: Renaming

Git does not explicitly track renames. The command

$ git mv old new

is equivalent to

$ mv old new
$ git add new
$ git rm old

Neither approach records the rename outright. However, Git's philosophy is "dumb add, smart view". It uses heuristics to detect renames when viewing history after-the-fact. It even works when the content of a renamed file changes slightly.

In order to help Git efficiently detect the rename, it is important to remove the old file and add the new one in one commit, perhaps by using git mv or the above 3-step procedure. If the new file were added in one commit and the old file removed in the next, Git would report this as a copy followed by a removal. It's copy-detection heuristics are more computationally intensive and must be explicitly enabled with the -C option to relevant operations (such as git blame).

Resources

Additional information about Git may be obtained at sites listed here.