Documentation: wording fixes in the user manual and glossary

Re-word the section on "Updating a repository with git fetch" in the
user manual.

Various other minor fixes in the manual and glossary.

Signed-off-by: Jeremiah Mahler <jmmahler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index be0858c188184eb510688ffc0598664541c1d10c..4e0b971824f698841a6395588c2b53b0e1cf988d 100644 (file)
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -1,7 +1,7 @@
 [[def_alternate_object_database]]alternate object database::
        Via the alternates mechanism, a <<def_repository,repository>>
        can inherit part of its <<def_object_database,object database>>
 [[def_alternate_object_database]]alternate object database::
        Via the alternates mechanism, a <<def_repository,repository>>
        can inherit part of its <<def_object_database,object database>>

-       from another object database, which is called "alternate".
+       from another object database, which is called an "alternate".

 
 [[def_bare_repository]]bare repository::
        A bare repository is normally an appropriately
 
 [[def_bare_repository]]bare repository::
        A bare repository is normally an appropriately

diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 022e74e616400664e7cf59ace487c8b53d6f5cab..46aa6bc1a67beef19b36db830d22662bf923913e 100644 (file)
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -416,12 +416,11 @@ REVISIONS" section of linkgit:gitrevisions[7].
 Updating a repository with git fetch
 ------------------------------------
 
 Updating a repository with git fetch
 ------------------------------------
 

-Eventually the developer cloned from will do additional work in her
-repository, creating new commits and advancing the branches to point
-at the new commits.
+After you clone a repository and commit a few changes of your own, you
+may wish to check the original repository for updates.

 
 

-The command `git fetch`, with no arguments, will update all of the
-remote-tracking branches to the latest version found in her
+The `git-fetch` command, with no arguments, will update all of the
+remote-tracking branches to the latest version found in the original

 repository.  It will not touch any of your own branches--not even the
 "master" branch that was created for you on clone.
 
 repository.  It will not touch any of your own branches--not even the
 "master" branch that was created for you on clone.
 


@@ -1811,8 +1810,8 @@ manner.
 You can then import these into your mail client and send them by
 hand.  However, if you have a lot to send at once, you may prefer to
 use the linkgit:git-send-email[1] script to automate the process.
 You can then import these into your mail client and send them by
 hand.  However, if you have a lot to send at once, you may prefer to
 use the linkgit:git-send-email[1] script to automate the process.

-Consult the mailing list for your project first to determine how they
-prefer such patches be handled.
+Consult the mailing list for your project first to determine
+their requirements for submitting patches.

 
 [[importing-patches]]
 Importing patches to a project
 
 [[importing-patches]]
 Importing patches to a project


@@ -2255,7 +2254,7 @@ $ git checkout test && git merge speed-up-spinlocks
 It is unlikely that you would have any conflicts here ... but you might if you
 spent a while on this step and had also pulled new versions from upstream.
 
 It is unlikely that you would have any conflicts here ... but you might if you
 spent a while on this step and had also pulled new versions from upstream.
 

-Some time later when enough time has passed and testing done, you can pull the
+Sometime later when enough time has passed and testing done, you can pull the

 same branch into the `release` tree ready to go upstream.  This is where you
 see the value of keeping each patch (or patch series) in its own branch.  It
 means that the patches can be moved into the `release` tree in any order.
 same branch into the `release` tree ready to go upstream.  This is where you
 see the value of keeping each patch (or patch series) in its own branch.  It
 means that the patches can be moved into the `release` tree in any order.