Some doc typo fixes
authorFrancis Daly <francis@daoine.org>
Wed, 7 Jun 2006 12:56:45 +0000 (13:56 +0100)
committerJunio C Hamano <junkio@cox.net>
Wed, 7 Jun 2006 18:49:35 +0000 (11:49 -0700)
All should be clear enough, except perhaps committish / commitish.
I just kept the more-used one within the current docs.

[jc: with rephrasing of check-ref-format description later discussed
on the list]

Signed-off-by: Francis Daly <francis@daoine.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/config.txt
Documentation/cvs-migration.txt
Documentation/everyday.txt
Documentation/git-check-ref-format.txt
Documentation/git-describe.txt
Documentation/git-name-rev.txt
Documentation/git-p4import.txt
Documentation/git-read-tree.txt
Documentation/hooks.txt
Documentation/tutorial.txt
index c861c6ce17f79e78e5b0fb6f61a5419d143fd369..4ce78679fed2f617ff3dd808ede061f5a94efff9 100644 (file)
@@ -113,12 +113,12 @@ gitcvs.logfile::
 
 http.sslVerify::
        Whether to verify the SSL certificate when fetching or pushing
 
 http.sslVerify::
        Whether to verify the SSL certificate when fetching or pushing
-       over HTTPS. Can be overriden by the 'GIT_SSL_NO_VERIFY' environment
+       over HTTPS. Can be overridden by the 'GIT_SSL_NO_VERIFY' environment
        variable.
 
 http.sslCert::
        File containing the SSL certificate when fetching or pushing
        variable.
 
 http.sslCert::
        File containing the SSL certificate when fetching or pushing
-       over HTTPS. Can be overriden by the 'GIT_SSL_CERT' environment
+       over HTTPS. Can be overridden by the 'GIT_SSL_CERT' environment
        variable.
 
 http.sslKey::
        variable.
 
 http.sslKey::
@@ -133,7 +133,7 @@ http.sslCAInfo::
 
 http.sslCAPath::
        Path containing files with the CA certificates to verify the peer
 
 http.sslCAPath::
        Path containing files with the CA certificates to verify the peer
-       with when fetching or pushing over HTTPS. Can be overriden
+       with when fetching or pushing over HTTPS. Can be overridden
        by the 'GIT_SSL_CAPATH' environment variable.
 
 http.maxRequests::
        by the 'GIT_SSL_CAPATH' environment variable.
 
 http.maxRequests::
index 826d0897e2fd2ad2f63677b477c9e1e0f62337ae..1fbca83141e20599e4d6edd880b1cabbf0cd9913 100644 (file)
@@ -106,7 +106,7 @@ Make sure committers have a umask of at most 027, so that the directories
 they create are writable and searchable by other group members.
 
 Suppose this repository is now set up in /pub/repo.git on the host
 they create are writable and searchable by other group members.
 
 Suppose this repository is now set up in /pub/repo.git on the host
-foo.com.  Then as an individual commiter you can clone the shared
+foo.com.  Then as an individual committer you can clone the shared
 repository:
 
 ------------------------------------------------
 repository:
 
 ------------------------------------------------
index 6745ab5fc5a1f1262edb9e2563627831b4b7f4bd..b935c180881571a964356e63a2e718c2721b5e6b 100644 (file)
@@ -45,7 +45,7 @@ Everybody uses these commands to feed and care git repositories.
 
   * gitlink:git-fsck-objects[1] to validate the repository.
 
 
   * gitlink:git-fsck-objects[1] to validate the repository.
 
-  * gitlink:git-prune[1] to garbage collect crufts in the
+  * gitlink:git-prune[1] to garbage collect cruft in the
     repository.
 
   * gitlink:git-repack[1] to pack loose objects for efficiency.
     repository.
 
   * gitlink:git-repack[1] to pack loose objects for efficiency.
index 3ea720dd005f7a9b4a66a419cf5438a3a7d0fa8b..13a5f43049c25e1df3bcbcbbed482acce0cebc8b 100644 (file)
@@ -19,8 +19,9 @@ branch head is stored under `$GIT_DIR/refs/heads` directory, and
 a tag is stored under `$GIT_DIR/refs/tags` directory.  git
 imposes the following rules on how refs are named:
 
 a tag is stored under `$GIT_DIR/refs/tags` directory.  git
 imposes the following rules on how refs are named:
 
-. It could be named hierarchically (i.e. separated with slash
-  `/`), but each of its component cannot begin with a dot `.`;
+. It can include slash `/` for hierarchical (directory)
+  grouping, but no slash-separated component can begin with a
+  dot `.`;
 
 . It cannot have two consecutive dots `..` anywhere;
 
 
 . It cannot have two consecutive dots `..` anywhere;
 
index 7a253eaf284ab8effc7138f91ba6236a4f05dfdd..2700f35bdb6ec7aae9520eca0d21bcf5089bc750 100644 (file)
@@ -21,7 +21,7 @@ object name of the commit.
 OPTIONS
 -------
 <committish>::
 OPTIONS
 -------
 <committish>::
-       The object name of the comittish. 
+       The object name of the committish.
 
 --all::
        Instead of using only the annotated tags, use any ref
 
 --all::
        Instead of using only the annotated tags, use any ref
index ffaa00468f0c16f19ab632aac20aaa74db52b325..39a1434a0e6be3c07852dc0919536bc63551a3dd 100644 (file)
@@ -8,7 +8,7 @@ git-name-rev - Find symbolic names for given revs
 
 SYNOPSIS
 --------
 
 SYNOPSIS
 --------
-'git-name-rev' [--tags] ( --all | --stdin | <commitish>... )
+'git-name-rev' [--tags] ( --all | --stdin | <committish>... )
 
 DESCRIPTION
 -----------
 
 DESCRIPTION
 -----------
index b8ff1e9bdebf04132a5b7dc85305ce0a20e95e09..c198ff2502d95be4dc1baadd6479b687acb0caa1 100644 (file)
@@ -128,7 +128,7 @@ Therefore after the import you can use git to access any commit by its
 Perforce number, eg. git show p4/327.
 
 The tag associated with the HEAD commit is also how `git-p4import`
 Perforce number, eg. git show p4/327.
 
 The tag associated with the HEAD commit is also how `git-p4import`
-determines if their are new changes to incrementally import from the
+determines if there are new changes to incrementally import from the
 Perforce repository.
 
 If you import from a repository with many thousands of changes
 Perforce repository.
 
 If you import from a repository with many thousands of changes
index 02c7e99fe6f6e49a5a0e03da7444bc559502585c..d894f537ba2634ed2719ee746b170a22f0173f56 100644 (file)
@@ -257,7 +257,7 @@ file that does not match stage 2.
 This is done to prevent you from losing your work-in-progress
 changes, and mixing your random changes in an unrelated merge
 commit.  To illustrate, suppose you start from what has been
 This is done to prevent you from losing your work-in-progress
 changes, and mixing your random changes in an unrelated merge
 commit.  To illustrate, suppose you start from what has been
-commited last to your repository:
+committed last to your repository:
 
 ----------------
 $ JC=`git-rev-parse --verify "HEAD^0"`
 
 ----------------
 $ JC=`git-rev-parse --verify "HEAD^0"`
index e3dde39190d7f69b2ca2482763a643d33f772b07..898b4aaf80aabe8caa9675c4371918a61312f1cb 100644 (file)
@@ -100,7 +100,7 @@ update
 This hook is invoked by `git-receive-pack` on the remote repository,
 which is happens when a `git push` is done on a local repository.
 Just before updating the ref on the remote repository, the update hook
 This hook is invoked by `git-receive-pack` on the remote repository,
 which is happens when a `git push` is done on a local repository.
 Just before updating the ref on the remote repository, the update hook
-is invoked.  It's exit status determines the success or failure of
+is invoked.  Its exit status determines the success or failure of
 the ref update.
 
 The hook executes once for each ref to be updated, and takes
 the ref update.
 
 The hook executes once for each ref to be updated, and takes
index db563127b236757de62be50a4e04439eddf2729e..554ee0af912368cb842d93c025e742daaf47f5f2 100644 (file)
@@ -357,7 +357,7 @@ $ git diff v2.5 HEAD         # compare the current HEAD to v2.5
 $ git branch stable v2.5 # start a new branch named "stable" based
                         # at v2.5
 $ git reset --hard HEAD^ # reset your current branch and working
 $ git branch stable v2.5 # start a new branch named "stable" based
                         # at v2.5
 $ git reset --hard HEAD^ # reset your current branch and working
-                        # directory its state at HEAD^
+                        # directory to its state at HEAD^
 -------------------------------------
 
 Be careful with that last command: in addition to losing any changes
 -------------------------------------
 
 Be careful with that last command: in addition to losing any changes