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 c861c6c..4ce7867 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 826d089..1fbca83 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 6745ab5..b935c18 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 3ea720d..13a5f43 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 7a253ea..2700f35 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 ffaa004..39a1434 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 b8ff1e9..c198ff2 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 02c7e99..d894f53 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 e3dde39..898b4aa 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 db56312..554ee0a 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