Git/Publish

Push Access

Authorized developers may publish work directly to a public.kitware.com repository using Git's SSH protocol.

Note that we may not grant all contributors push access to any given repository. The distributed nature of Git allows contributors to retain authorship credit even if they do not publish changes directly.

Authentication

All publishers share the git@public.kitware.com account but each uses a unique ssh key for authentication. If you do not have a public/private ssh key pair, generate one:

$ ssh-keygen -C 'you@yourdomain.com'
Generating public/private rsa key pair.
Enter file in which to save the key ($HOME/.ssh/id_rsa):
Enter passphrase (empty for no passphrase): (use-a-passphrase!!)
Enter same passphrase again: (use-same-passphrase!!)
Your identification has been saved in $HOME/.ssh/id_rsa.
Your public key has been saved in $HOME/.ssh/id_rsa.pub.

To request access, fill out the Kitware Password form. Include your ssh public key, id_rsa.pub, and a reference to someone our administrators may contact to verify your privileges.

SSH on Windows

If you are familiar with generating an ssh key on Linux or Mac, you can follow the same procedure on Windows in a "Git Bash" prompt. There is an ssh-keygen program installed with msysGit to help you set up an ssh identity on a Windows machine. By default it puts the ".ssh" directory in the HOME directory, which is typically "/c/Users/Username" on Vista and Windows 7; on XP, it's "/c/Documents and Settings/Username".

Alternatively, you can also set up a "normal" Windows command prompt shell such that it will work with msysGit, without ever invoking the Git Bash prompt if you like. If you install msysGit and accept all its default options, "git" will not be in the PATH. However, if you add "C:\Program Files (x86)\Git\cmd" to your PATH, then only the two commands git and gitk are available to use via *.cmd script wrappers installed by msysGit. Or, if you add "C:\Program Files (x86)\Git\bin" to your PATH, then all of the command line tools that git installs are available.

The full PuTTY suite of tools includes an application called PuTTYgen. If you already have a private key created with PuTTYgen, you may export it to an OpenSSH identity file. Open the key using PuTTYgen and choose "Conversions > Export OpenSSH key" from the menu bar. That will allow you to save an "id_rsa" file for use in the ".ssh" directory. You can also copy and paste the public key portion of the key from the PuTTYgen text field to save into an "id_rsa.pub" file if you like. Or email it to whoever needs the public side of your key pair.

If you routinely set up your own command prompt environment on Windows, using msysGit from that envrionment is a cinch: just add the full path to either Git\cmd or Git\bin to your PATH. (Or, write your own git.cmd wrapper that is in your PATH that simply calls the git.cmd installed with msysGit.) And make sure you have a HOME environment variable that points to the place where the .ssh directory is.

Authentication Test

When your ssh public key has been installed for git@public.kitware.com, you may test your ssh key setup by running

$ ssh git@public.kitware.com info

If your key is correctly configured you should see a message reporting your email address followed by a list of access permissions. If you get something like "Permission denied" then add -v options to your ssh command line to diagnose the problem:

$ ssh -v git@public.kitware.com info

Do not attempt to git push until the ssh-only test succeeds.

Pushing

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 a public.kitware.com 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@public.kitware.com:repo.git

The actual URL will vary from project to project. (Note that 'pushurl' requires Git >= 1.6.4. Use just 'url' for Git < 1.6.4.)

Failing to do so with result in the following error message: "fatal: The remote end hung up unexpectedly".

Once your push URL is configured and your key is installed for git@public.kitware.com then you can try pushing changes. Note that many repositories use an update hook to check commit as documented here.

Patches

Git allows anyone to be a first-class developer on any published project. One can clone a public repository, commit locally, and publish these commits for inclusion upstream. One method of sending commits upstream is to supply them as patches.

See these links for more help:

• Pro Git Book, Chapter 5: Distributed Git
• Everyday GIT: Integrator

Creating Patches

Construct your commits on a local topic branch, typically started from the upstream master:

$ git checkout -b my-cool-feature origin/master
$ edit files
$ git add -- files
$ git commit

Begin each commit message with a short one-line summary of its change, suitable for use as an email subject line. Then leave a blank line and describe the change in detail as one might write in an email body.

When the patch(es) are ready for publication to upstream developers, use the git format-patch command to construct the patch files:

$ git format-patch -M origin/master

Git will write out one patch file per commit. Each patch file is formatted like a raw email message and includes enough information to reconstruct the commit message and author.

Sending Patches

The patch files created in the preceding step will be named with the form

NNNN-Subject-line-of-commit-message.patch

where NNNN is an index for the patch within the series. These files may be attached in bug trackers or attached to email messages.

A patch series may also be sent directly as email. Use git config --global to set sendemail.* configuration entries that tell Git how to send email from your computer (one-time setup per user per machine). Then use the git send-email command:

$ git send-email *.patch --to='Some One <someone@somewhere.com>' --cc='Someone Else <someoneelse@somewhereelse.com>'

Applying Patches

One may receive patches as attachments in a bug tracker or as attachments to email messages. Save these files to your local disk. One may also receive patches inlined in email messages. In this case, save the whole message to your local disk (typically as .eml files). (If your local mail client uses "maildir" format mailboxes each message is already its own file.)

Create a local topic branch on which to replay the patch series:

$ git checkout -b cool-feature origin/master

Now use git am to apply the patch series as local commits:

$ git am --whitespace=fix /path/to/*.patch

Review the changes using

$ git log -p origin/master..

or the method of your choice. Note that the author of each commit is the contributor rather than yourself. Build, test, and publish the changes normally.

If the "git am" command fails with a message like

Patch format detection failed.

this means that the patch was not generated with git format-patch and transmitted correctly. Either ask the contributor to try again using the above patch creation instructions, or apply each patch separately using git apply:

$ git apply --whitespace=fix /path/to/0001-First-change.patch
$ git commit --author='Contributor Name <contributor@theirdomain.com>'