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>
Jeremiah Mahler committed
May 27, 2014 at 19:23 UTC
3c735e0776e11951631c6b7a181c655f5742011b
2 files changed
+8
-9
Documentation/glossary-content.txt
+1
-1
@@ -1,7 +1,7 @@
1
[[def_alternate_object_database]]alternate object database::
2
Via the alternates mechanism, a <<def_repository,repository>>
3
can inherit part of its <<def_object_database,object database>>
4
- from another object database, which is called "alternate".
4
+ from another object database, which is called an "alternate".
5
6
[[def_bare_repository]]bare repository::
7
A bare repository is normally an appropriately
Documentation/user-manual.txt
+7
-8
@@ -416,12 +416,11 @@ REVISIONS" section of linkgit:gitrevisions[7].
416
Updating a repository with git fetch
417
------------------------------------
418
419
-Eventually the developer cloned from will do additional work in her
420
-repository, creating new commits and advancing the branches to point
421
-at the new commits.
419
+After you clone a repository and commit a few changes of your own, you
420
+may wish to check the original repository for updates.
421
423
-The command `git fetch`, with no arguments, will update all of the
424
-remote-tracking branches to the latest version found in her
422
+The `git-fetch` command, with no arguments, will update all of the
423
+remote-tracking branches to the latest version found in the original
424
repository. It will not touch any of your own branches--not even the
425
"master" branch that was created for you on clone.
426
@@ -1811,8 +1810,8 @@ manner.
1810
You can then import these into your mail client and send them by
1811
hand. However, if you have a lot to send at once, you may prefer to
1812
use the linkgit:git-send-email[1] script to automate the process.
1814
-Consult the mailing list for your project first to determine how they
1815
-prefer such patches be handled.
1813
+Consult the mailing list for your project first to determine
1814
+their requirements for submitting patches.
1815
1816
[[importing-patches]]
1817
Importing patches to a project
@@ -2255,7 +2254,7 @@ $ git checkout test && git merge speed-up-spinlocks
2254
It is unlikely that you would have any conflicts here ... but you might if you
2255
spent a while on this step and had also pulled new versions from upstream.
2256
2258
-Some time later when enough time has passed and testing done, you can pull the
2257
+Sometime later when enough time has passed and testing done, you can pull the
2258
same branch into the `release` tree ready to go upstream. This is where you
2259
see the value of keeping each patch (or patch series) in its own branch. It
2260
means that the patches can be moved into the `release` tree in any order.