Some doc typo fixes

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

@@ -113,12 +113,12 @@ gitcvs.logfile::
 
 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
-	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::
@@ -133,7 +133,7 @@ http.sslCAInfo::
 
 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::

Documentation/cvs-migration.txt

@@ -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
-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:
 
 ------------------------------------------------

Documentation/everyday.txt

@@ -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-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.

Documentation/git-check-ref-format.txt

@@ -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:
 
-. 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;
 

Documentation/git-describe.txt

@@ -21,7 +21,7 @@ object name of the commit.
 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

Documentation/git-name-rev.txt

@@ -8,7 +8,7 @@ git-name-rev - Find symbolic names for given revs
 
 SYNOPSIS
 --------
-'git-name-rev' [--tags] ( --all | --stdin | <commitish>... )
+'git-name-rev' [--tags] ( --all | --stdin | <committish>... )
 
 DESCRIPTION
 -----------

Documentation/git-p4import.txt

@@ -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`
-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

Documentation/git-read-tree.txt

@@ -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
-commited last to your repository:
+committed last to your repository:
 
 ----------------
 $ JC=`git-rev-parse --verify "HEAD^0"`

Documentation/hooks.txt

@@ -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
-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

Documentation/tutorial.txt

@@ -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
-			 # directory its state at HEAD^
+			 # directory to its state at HEAD^
 -------------------------------------
 
 Be careful with that last command: in addition to losing any changes