contrib/examples/git-clone.sh: avoid "test <cond> -a/-o <cond>"
[gitweb.git] / Documentation / user-manual.txt
index 248dcabd50fb1fb844eaf27090b2f7f45bb0e661..d33f8849b5af3a6946811fea1f78684726e7cde4 100644 (file)
@@ -3795,7 +3795,7 @@ like so:
 $ git update-index filename
 -------------------------------------------------
 
-but to avoid common mistakes with filename globbing etc, the command
+but to avoid common mistakes with filename globbing etc., the command
 will not normally add totally new entries or remove old entries,
 i.e. it will normally just update existing cache entries.
 
@@ -4074,7 +4074,7 @@ the `HEAD` tree, and stage 3 to the `$target` tree.
 
 Earlier we said that trivial merges are done inside
 `git read-tree -m`.  For example, if the file did not change
-from `$orig` to `HEAD` nor `$target`, or if the file changed
+from `$orig` to `HEAD` or `$target`, or if the file changed
 from `$orig` to `HEAD` and `$orig` to `$target` the same way,
 obviously the final outcome is what is in `HEAD`.  What the
 above example shows is that file `hello.c` was changed from
@@ -4231,9 +4231,9 @@ Most of what `git rev-list` did is contained in `revision.c` and
 controls how and what revisions are walked, and more.
 
 The original job of `git rev-parse` is now taken by the function
-`setup_revisions()`, which parses the revisions and the common command line
+`setup_revisions()`, which parses the revisions and the common command-line
 options for the revision walker. This information is stored in the struct
-`rev_info` for later consumption. You can do your own command line option
+`rev_info` for later consumption. You can do your own command-line option
 parsing after calling `setup_revisions()`. After that, you have to call
 `prepare_revision_walk()` for initialization, and then you can get the
 commits one by one with the function `get_revision()`.