|
|
| (83 intermediate revisions by 11 users not shown) |
| Line 1: |
Line 1: |
| __TOC__
| | The instructions previously available on this page have been superseded. See [https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/README.md here]. |
| | |
| VTK version tracking and development is hosted by [http://git-scm.com Git].
| |
| | |
| =Official Repository=
| |
| | |
| One may browse the repository online using the [http://git.wiki.kernel.org/index.php/Gitweb Gitweb] interface at http://vtk.org/gitweb.
| |
| | |
| ==Cloning==
| |
| | |
| One may clone the repository using [http://www.kernel.org/pub/software/scm/git/docs/git-clone.html git clone] through the native <code>git</code> protocol:
| |
| | |
| $ git clone git://vtk.org/VTK.git VTK
| |
| | |
| or through the (less efficient) <code>http</code> protocol:
| |
| | |
| $ git clone http://vtk.org/VTK.git VTK
| |
| | |
| All further commands work inside the local copy of the repository created by the clone:
| |
| | |
| $ cd VTK
| |
| | |
| For VTKData the URLs are
| |
| | |
| git://vtk.org/VTKData.git
| |
| http://vtk.org/VTKData.git
| |
| | |
| ==Branches==
| |
| | |
| At the time of this writing the repository has the following branches:
| |
| | |
| * '''master''': Development (default)
| |
| * '''hooks''': Local commit hooks ([[#Hooks|place]] in .git/hooks)
| |
| | |
| Release branches converted from CVS have been artificially merged into master.
| |
| Actual releases have tags named by the release version number.
| |
| | |
| =Development=
| |
| | |
| We provide here a brief introduction to '''VTK''' development with Git.
| |
| See the [[#Resources|Resources]] below for further information such as Git tutorials.
| |
| | |
| ==Introduction==
| |
| | |
| We require all commits in VTK to record valid author/committer name and email information.
| |
| Use [http://www.kernel.org/pub/software/scm/git/docs/git-config.html 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
| |
| | |
| The <code>--global</code> option stores the configuration settings in <code>~/.gitconfig</code> in your home directory so that they apply to all repositories.
| |
| | |
| ==Hooks==
| |
| | |
| This step is ''optional'' but recommended.
| |
| | |
| The [http://www.kernel.org/pub/software/scm/git/docs/git-commit.html git commit] command creates ''local'' commits.
| |
| A separate [http://www.kernel.org/pub/software/scm/git/docs/git-push.html git push] step is needed to publish commits to <code>vtk.org/VTK.git</code>.
| |
| The <code>vtk.org</code> server enforces some rules on the commits it accepts and will reject non-conforming commits. See [[#Update_Hook|below]]. | |
| In order to push rejected commits, one must ''edit'' history locally to repair them before publishing.
| |
| | |
| Since it is possible to create many commits locally and push them all at once, we provide local Git ''hooks'' to help developers keep their individual commits clean.
| |
| Git provides no way to enable such hooks by default, giving developers maximum control over their local repositories.
| |
| We recommend enabling our hooks manually in all clones.
| |
| | |
| Git looks for hooks in the <code>.git/hooks</code> directory within the work tree of a local repository.
| |
| Create a new ''local'' repository in this directory to manage the hooks:
| |
| | |
| $ cd .git/hooks
| |
| $ git init
| |
| | |
| The <code>vtk.org/VTK.git</code> repository provides a <code>hooks</code> branch.
| |
| It will have already been fetched into your local clone.
| |
| Pull it from there:
| |
| | |
| $ git pull .. remotes/origin/hooks
| |
| $ cd ../..
| |
| | |
| The hooks will now run in the outer repository to enforce some rules on commits.
| |
| To update the hooks in the future, run
| |
| | |
| $ git fetch origin
| |
| $ cd .git/hooks
| |
| $ git pull .. remotes/origin/hooks
| |
| | |
| The above sequence maintains the following local hooks in your repository.
| |
| See Git help on [http://www.kernel.org/pub/software/scm/git/docs/githooks.html githooks] for more details.
| |
| | |
| ===pre-commit===
| |
| | |
| This runs during <code>git commit</code>. It checks identity and content of changes:
| |
| | |
| * Git <code>user.name</code> and <code>user.email</code> are set to something reasonable
| |
| * Git's standard whitespace checks (see help on <code>git diff --check</code>)
| |
| * The staged changes do not introduce any leading TABs in source files (we indent with spaces)
| |
| * File modes look reasonable (no executable .cxx files, scripts with shebang lines are executable)
| |
| * File size is not too large (don't commit big data files; prints limit and instructions on rejection)
| |
| | |
| One of Git's standard whitespace checks is to reject ''trailing'' whitespace on lines that were added or modified.
| |
| Many people consider extra space characters at the end of a line to be an unprofessional style (including Git's own developers), but some don't care.
| |
| Text editors typically have a mode to highlight trailing whitespace:
| |
| | |
| {|
| |
| |-
| |
| |width=20%|Emacs
| |
| |
| |
| (custom-set-variables '(show-trailing-whitespace t))
| |
| |-
| |
| |width=20%|Vim
| |
| |
| |
| :highlight ExtraWhitespace ctermbg=red guibg=red
| |
| :match ExtraWhitespace /\s\+$/
| |
| |-
| |
| |width=20%|Visual Studio
| |
| |
| |
| To toggle viewing of white space characters, with a source
| |
| file document active, choose the menu item:
| |
|
| |
| '''Edit > Advanced > View White Space'''
| |
|
| |
| (2-stroke keyboard shortcut: '''Ctrl+R, Ctrl+W''')
| |
| |-
| |
| |width=20%|Notepad++ (v5.6.7)
| |
| |
| |
| To eliminate trailing white space, choose the menu item:
| |
|
| |
| '''Edit > Trim Trailing Space'''
| |
|
| |
| To toggle viewing of white space characters, choose from the
| |
| menu items:
| |
|
| |
| '''View > Show Symbol >''' (multiple items, choose one...)
| |
| |}
| |
| | |
| If you ''really'' don't want to keep your code clean of trailing whitespace, you can disable this part of Git's checks locally:
| |
| | |
| $ git config core.whitespace "-blank-at-eol"
| |
| | |
| ===commit-msg===
| |
| | |
| This runs during <code>git commit</code>. It checks the commit message format:
| |
| | |
| * The first line must be between 8 and 78 characters long. If you were writing an email to describe the change, this would be the Subject line. <br> (Do not bother using 'ENH:' or 'BUG:' prefixes; they take space and are less valuable than a good summary on this line).
| |
| * The first line must not have leading or trailing whitespace.
| |
| * The second line must be blank, if present.
| |
| * The third line and below may be free-form. Try to keep paragraph text formatted in 72 columns (this is not enforced).
| |
| | |
| GUI and text-based tools that help view history typically use the first line (Subject line) from the commit message to give a one-line summary of each commit.
| |
| This allows a medium-level view of history, but works well only if developers write good Subject lines for their commits.
| |
| | |
| Examples of ''improper'' commit messages:
| |
| | |
| Fixed
| |
| | |
| This is too short and not informative at all.
| |
| | |
| I did a really complicated change and I am trying to describe the entire thing with a big message entered on the command line.
| |
| | |
| Many CVS users develop the habit of using the "-m" commit option to specify the whole message on the command line.
| |
| This is probably because in CVS it is hard to abort a commit if it already brought up the message editor.
| |
| In Git this is trivial. Just leave the message blank and the whole commit will be aborted.
| |
| Furthermore, since commits are not published automatically it is easy to allow the commit to complete and then fix it with <code>git commit --amend</code>.
| |
| | |
| ==Workflow==
| |
| | |
| We've chosen to approximate our previous CVS-based development workflow after the initial move to Git, at least while things get settled.
| |
| See [http://www.cmake.org/Wiki/CMake/Git#Workflow here] for more detailed instructions.
| |
| The basic rule is to rebase your work on origin/master before pushing:
| |
| | |
| git fetch origin
| |
| git rebase origin/master
| |
| | |
| or
| |
| | |
| git pull --rebase
| |
| | |
| The server will refuse your push if it contains any merges.
| |
| Later we will move to branchy development as described in the [http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html#_managing_branches gitworkflows] man page.
| |
| | |
| =Publishing=
| |
| | |
| Authorized developers may publish work directly to <code>vtk.org/VTK.git</code> using Git's SSH protocol.
| |
| | |
| Note that ''we may not grant all contributors push access'' to the <code>vtk.org</code> repository.
| |
| The distributed nature of Git allows contributors to retain authorship credit even if they do not publish changes directly.
| |
| | |
| If you are an external contributor without push access, you can submit a patch to the vtk-developers mailing list, see [[#Submitting_a_patch]].
| |
| | |
| ==Authentication==
| |
| | |
| All publishers share the <code>git@vtk.org</code> 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 [https://www.kitware.com/Admin/SendPassword.cgi Kitware Password] form.
| |
| Include your ssh public key, '''<code>id_rsa.pub</code>''', and a reference to someone our administrators may contact to verify your privileges.
| |
| | |
| ===Generating an ssh key 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.
| |
| | |
| ==Pushing==
| |
| | |
| Git automatically configures a new clone to refer to its origin through a [http://www.kernel.org/pub/software/scm/git/docs/git-remote.html remote] called <code>origin</code>.
| |
| Initially one may [http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html fetch] or [http://www.kernel.org/pub/software/scm/git/docs/git-pull.html pull] changes from <code>origin</code>,
| |
| but may not [http://www.kernel.org/pub/software/scm/git/docs/git-push.html push] changes to it.
| |
| | |
| In order to publish new commits in the <code>vtk.org</code> repository, developers must configure a ''push URL'' for the <code>origin</code>.
| |
| Use [http://www.kernel.org/pub/software/scm/git/docs/git-config.html git config] to specify an ssh-protocol URL:
| |
| | |
| $ git config remote.origin.pushurl git@vtk.org:VTK.git
| |
| | |
| (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 <code>git@vtk.org</code> then you can try pushing changes.
| |
| | |
| For VTKData, the push URL is
| |
| | |
| git@vtk.org:VTKData.git
| |
| | |
| ===Update Hook===
| |
| | |
| The vtk.org repository has an <code>update</code> hook.
| |
| It runs when someone tries to update a ref on the server by pushing.
| |
| The hook checks all commits included in the push:
| |
| | |
| * Commit author and committer must have valid email address domains (DNS lookup succeeds).
| |
| * Commit message does not start with "<code>WIP:</code>". (Use the prefix locally for work-in-progress that must be rewritten before publishing.)
| |
| * Changes to paths updated by robots (such as Utilities/kwsys) are not allowed.
| |
| * No "large" blobs may be pushed. The limit is 1MB at the time of this writing.
| |
| * No CRLF newlines may be added in the repository (see core.autocrlf in <code>git help config</code>).
| |
| * Submodules (if any) must be pushed before the references to them are pushed.
| |
| | |
| = Submitting a patch =
| |
| If you are an external contributor without push access, you can submit a patch to the vtk-developers mailing list.
| |
| # subscribe to the vtk-developers mailing list: http://www.vtk.org/mailman/listinfo/vtk-developers
| |
| # prepare your patch:
| |
| <pre>
| |
| # 1. pull from the central repository with rebase, not merge
| |
| $ cd VTK
| |
| $ git pull --rebase
| |
| </pre>
| |
| <pre>
| |
| # 2. create the patch
| |
| $ git format-patch
| |
| </pre>
| |
| 3. send the patch to the vtk-developers list
| |
| | |
| A contributor with push access will be able to apply the patch and push it to the central repository. See the following section to apply a patch [[#Applying_a_patch]] .
| |
| | |
| = Applying a patch =
| |
| When you receive a patch by email, you can apply it locally with:
| |
| <pre>
| |
| $ cd VTK
| |
| $ git am -3 -i -s -u patch.txt
| |
| </pre>
| |
| | |
| If the following error happen:
| |
| <pre>
| |
| Patch format detection failed.
| |
| </pre>
| |
| It means the patch was not generated with <tt>git format-patch</tt> but with <tt>git show</tt>
| |
| | |
| To apply a patch generated with <tt>git show</tt>, use
| |
| <pre>
| |
| $ cd VTK
| |
| $ git apply --whitespace=fix patch.txt
| |
| </pre>
| |
| | |
| Now you have applied the patch, you can review it and test it.
| |
| | |
| If you are a contributor with push access, you can decide to reject or accept the patch and maybe apply additional commits. At this point, you are ready to publish the patch to the central repository [[#Publishing]] .
| |
| | |
| = Troubleshooting =
| |
| == fatal: The remote end hung up unexpectedly ==
| |
| * If <tt>git push</tt> fails with "fatal: The remote end hung up unexpectedly", you probably forgot to set the push url with "git config" see [[#Pushing]].
| |
| | |
| == Restoring files locally ==
| |
| Q: "I cloned the VTK repository. Now I "rm -rf Hybrid". How do I get it back?"<br>
| |
| A: git checkout Hybrid<br>
| |
| Q: "I modified a file locally. I want to revert it."<br>
| |
| A: git checkout myfile.cxx
| |
| | |
| =Resources=
| |
| | |
| Additional information about Git may be obtained at these sites:
| |
| | |
| * [http://git-scm.com Git Homepage]
| |
| * [http://git.wiki.kernel.org/index.php/GitDocumentation Git Documentation Wiki]
| |
| * [http://book.git-scm.com/ Git Community Book]
| |
| * [http://www.kernel.org/pub/software/scm/git/docs/everyday.html Everyday Git]
| |
| * [http://github.com/guides/git-cheat-sheet Git Cheat-Sheet]
| |
| * [http://progit.org/book/ Pro Git]
| |
| * [http://marklodato.github.com/visual-git-guide/ A Visual Git Reference]
| |
