Git opens up a number of new options for contributing to OpenAFS. For the first time, it is easy to review code that is pending addition to the OpenAFS tree. In fact, reviewing code is one of the best ways to ensure that the releases that OpenAFS ships remain stable and functional. If you are interested purely in reviewing, then please skip to that section towards the end of this document.
-Git also changes the way that developers interact with the OpenAFS tree. Instead of just having a single version of the tree on your local machine, you have a compressed copy of the entire repository. Additionally, you no longer have to produce patches to send code upstream - any developer can push into the OpenAFS repository directly, through gerrit, our code review tool.
+Git also changes the way that developers interact with the OpenAFS tree. Instead of just having a single version of the tree on your local machine, you have a compressed copy of the entire repository. Additionally, you no longer have to produce patches to send code upstream - any developer can push into the OpenAFS repository directly, through gerrit, our code review tool. [New Home Construction](http://www.dwh.co.uk)
Whilst git is a far more powerful tool than CVS it is also, inevitably, more complex. This document can only scratch the surface of what's possible with git - there are many, many, documents available that describe git in greater detail, and references to some of them are provided at the end.
Firstly, if your machine doesn't already have it installed, get a copy of the 'git' version control system. This is available for many platforms from their upstream package repositories or, failing that, can be downloaded in both source and binary form from <http://git-scm.com/download>
-## <a name="Getting the _OpenAFS repository"></a> Getting the OpenAFS repository
+## <a name="Getting the _OpenAFS repository"></a> Getting the OpenAFS repository [PPI Claims UK](http://www.gladstonebrookes.co.uk/)
You can download the entire OpenAFS repository by running
This puts me on a new branch, ready to start writing code. All new development should be based upon the origin/master branch, submissions based upon other branches are unlikely to be accepted, unless they address issues that are solely present in that branch.
-'git add' is used to tell git about any new files you create as part of your patch. If your patch results in any new compilation products (object files, new executables, etc) that git should not be tracking, please make sure that they're caught by the .gitignore mechanism. You can do this by checking that they don't appear in the output from 'git status'
+'git add' is used to tell git about any new files you create as part of your patch. If your patch results in any new compilation products (object files, new executables, etc) that git should not be tracking, please make sure that they're caught by the .gitignore mechanism. You can do this by checking that they don't appear in the output from 'git status' [Data Recovery Austin](http://www.securedatarecovery.com/data-recovery-austin.html)
'git mv' and 'git rm' are used to move and delete files respectively.
It's possible that your modifications won't be accepted first time. In this case, you need to revise your changes, and resubmit them to gerrit. Please note that this should always be done by modifying your original changeset, _not_ by submitting a new change that makes the required fixes. Either git commit --amend, or git rebase should be used to combine your changes with the original changeset, and then you should push this to gerrit with
git push ssh://gerrit.openafs.org/openafs.git <hash>:refs/changes/<number>
-
-(where <hash> is the sha1 hash of the revised change, and <number> is the change number you received when you originally submitted the patch)
+
+(where <hash> is the sha1 hash of the revised change that follows the word <tt>commit</tt> in the log message, and <number> is the change number you received when you originally submitted the patch)
You can obtain the sha1 hash of a commit by using 'git show' (if it is on the tip of your current branch), or 'git log' (if it is in your history)
## <a name="Updating your change"></a> Updating your change
-It's possible that your change may have been made against a tree which is too old for it to apply to the tip. In this case, gerrit will let you know that there is a collision, and request that you update the change to the tip.
+It's possible that your change may have been made against a tree which is too old for it to apply to the tip. In this case, gerrit will let you know that there is a collision, and request that you update the change to the tip. [Buy Homes](http://www.barratthomes.co.uk/Find-a-Home/)
You can do this with
Git User's Manual <http://www.kernel.org/pub/software/scm/git/docs/user-manual.html>
-Git Community Book <http://book.git-scm.com/>
+Git Community Book <http://book.git-scm.com/>
Gerrit Documentation <http://gerrit.googlecode.com/svn/documentation/2.0/index.html> (only the first 'User Guide' section of this document is relevant)