none

diff --git a/AFSLore/GitDevelopers.mdwn b/AFSLore/GitDevelopers.mdwn
index f05e581..2e12846 100644 (file)
--- a/AFSLore/GitDevelopers.mdwn
+++ b/AFSLore/GitDevelopers.mdwn
@@ -36,7 +36,7 @@ will pull all of the new changes into your local repository, and merge those cha
 
 The OpenAFS repository contains many branches, most of which are historical and should not be used for new development. Current development should be targetted at 'master' (for feature work, and general bugfixing), or at 'openafs-stable-1\_4\_x' (bug fixes specific to the current stable release). Note that the openafs-devel-1\_5\_x branch is now effectively dead - future 1.5 releases will occur from the 'master' branch.
 
-A complete list of all branches can be obtained by running
+A complete list of all branches in the upstream OpenAFS repository can be obtained by running
 
     git branch -r
 
@@ -74,7 +74,7 @@ Again, whilst a direct checkout of a remote tag is fine for code browsing, it sh
 
 ## <a name="Viewing deltas"></a> Viewing deltas
 
-In git, a delta should be simply a single changeset. Deltas are represented by means of a special form of git tag, allowing you to locally view the change, and commit message, that corresponds to each one. In order to keep down the transfer size, deltas are not included in the repository you get when you do a git clone - there are over 10,000 delta references, and having them in your local repository can cause performance issues. If you really wish to be able to locally browse deltas, then run the following
+OpenAFS's original CVS repository used the concept of deltas as a means of grouping a large number of related changes into a single item, which could be easily fetched and referred to. In git, a delta should be simply a single commit. Deltas are represented by means of a special form of git tag, allowing you to locally view the change and commit message that corresponds to each one. In order to keep down the transfer size, deltas are not included in the repository you get when you do a git clone - there are over 10,000 delta references, and having them in your local repository can cause performance issues. If you really wish to be able to locally browse deltas, then run the following
 
     git config --add remote.origin.fetch '+refs/deltas/*:refs/remotes/deltas/*'
     git fetch origin
@@ -83,7 +83,7 @@ You can then view a specific delta by doing
 
     git show refs/remotes/deltas/<branch>/<delta>
 
-Sadly, historical accidents mean that not all of our deltas can be represented by means of single commit. Where this is the case, a delta-name will have a trailing -part-, where each of these numbers must be used to form the complete delta. This only applies to some deltas created before the git conversion - all deltas created from now on will be a single changeset.
+Sadly, historical accidents mean that not all of our deltas can be represented by means of single commit. Where this is the case, a delta-name will have a trailing -part-, where each of these numbers must be used to form the complete delta. This only applies to some deltas created before the git conversion - all deltas created from now on will be single commits.
 
 ## <a name="Introducing yourself to git"></a> Introducing yourself to git
 
@@ -107,7 +107,7 @@ Before creating a new topic branch, running
 
     git fetch
 
-will make sure that your repository is up to date (unlike git pull, this will not update any files that you may have checked out)
+will make sure that your repository knows about the latest upstream changes (unlike git pull, this will not update any files that you may have checked out)
 
 To create a new topic branch:
 
@@ -117,7 +117,7 @@ For example, to work on a patch to fix printf warnings, based on the current dev
 
     git checkout -b fix-printf-warnings origin/master
 
-This puts me on a new branch, ready to start writing code. We'd strongly recommend that all new development is based upon the origin/master branch, submissions based upon other branches are unlikely to be accepted.
+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'
 
@@ -141,7 +141,7 @@ will restore &lt;file&gt; to the state it was in at the last commit.
 
 If you're working on a long running development project, you will find that the point your created your topic branch rapidly recedes into history. At some point (and at least before you share your code with us), you'll probably want to update your tree. There are a number of ways of doing this.
 
-If you haven't shared you tree with anyone else, then you can use
+If you haven't shared your tree with anyone else, then you can use
 
     git rebase <branch> <topic>
 
@@ -200,9 +200,9 @@ Secondly, each commit should have a meaningful revision log. The internals of gi
 
 Once you have commits in this form, use
 
-    git log -p <branch>..HEAD
+    git log -p origin/<branch>..HEAD
 
-(where &lt;branch&gt; is the upstream branch upon which you are basing this patch)
+(where &lt;branch&gt; is the upstream branch upon which you are basing this patch).
 
 to check that what you're giving us makes sense. Then, upload them to gerrit using