Merge branch 'ta/doc-no-small-caps'

Update documentation to change "GIT" which was a poor-man's small
caps to "Git".  The latter was the intended spelling.

Also change "git" spelled in all-lowercase to "Git" when it refers
to the system as the whole or the concept it embodies, as opposed to
the command the end users would type.

* ta/doc-no-small-caps:
  Documentation: StGit is the right spelling, not StGIT
  Documentation: describe the "repository" in repository-layout
  Documentation: add a description for 'gitfile' to glossary
  Documentation: do not use undefined terms git-dir and git-file
  Documentation: the name of the system is 'Git', not 'git'
  Documentation: avoid poor-man's small caps GIT

diff --cc Documentation/config.txt
Simple merge

diff --cc Documentation/git-cvsimport.txt
index f059ea94daf72dc66c9e04455b4fdbb235875c52,1786d9dc9636a981ad088151c7f4a5d081931315..d1bcda28f423566dff17a7bff85f40ae07d4ca9a
--- 1/Documentation/git-cvsimport.txt
--- 2/Documentation/git-cvsimport.txt
+++ b/Documentation/git-cvsimport.txt
@@@ -18,13 -18,7 +18,13 @@@ SYNOPSI
  
  DESCRIPTION
  -----------
- Imports a CVS repository into git. It will either create a new
 +*WARNING:* `git cvsimport` uses cvsps version 2, which is considered
 +deprecated; it does not work with cvsps version 3 and later.  If you are
 +performing a one-shot import of a CVS repository consider using
 +link:http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or
 +link:https://github.com/BartMassey/parsecvs[parsecvs].
 +
+ Imports a CVS repository into Git. It will either create a new
  repository, or incrementally import into an existing one.
  
  Splitting the CVS log into patch sets is done by 'cvsps'.

diff --cc Documentation/git-cvsserver.txt
Simple merge

diff --cc Documentation/git-p4.txt
index f70ef9ded2c7e476c60a90f15ef45e650c663bde,3417cb3f596c6f99177da58e2e0365ee1236c560..c579fbc2b858d0a6fb5cd8dcbcaa25d3b3fca2a5
--- 1/Documentation/git-p4.txt
--- 2/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@@ -107,16 -107,11 +107,16 @@@ This imports the specified depot int
  '--branch' option can be used to specify a different branch to
  be used for the p4 content.
  
- If a git repository includes branches 'refs/remotes/origin/p4', these
+ If a Git repository includes branches 'refs/remotes/origin/p4', these
  will be fetched and consulted first during a 'git p4 sync'.  Since
  importing directly from p4 is considerably slower than pulling changes
- from a git remote, this can be useful in a multi-developer environment.
+ from a Git remote, this can be useful in a multi-developer environment.
  
 +If there are multiple branches, doing 'git p4 sync' will automatically
 +use the "BRANCH DETECTION" algorithm to try to partition new changes
 +into the right branch.  This can be overridden with the '--branch'
 +option to specify just a single branch to update.
 +
  
  Rebase
  ~~~~~~
@@@ -178,14 -173,12 +178,14 @@@ subsequent 'sync' operations
  
  --branch <branch>::
        Import changes into given branch.  If the branch starts with
 -      'refs/', it will be used as is, otherwise the path 'refs/heads/'
 -      will be prepended.  The default branch is 'master'.  If used
 -      with an initial clone, no HEAD will be checked out.
 +      'refs/', it will be used as is.  Otherwise if it does not start
 +      with 'p4/', that prefix is added.  The branch is assumed to
 +      name a remote tracking, but this can be modified using
 +      '--import-local', or by giving a full ref name.  The default
 +      branch is 'master'.
  +
  This example imports a new remote "p4/proj2" into an existing
- git repository:
+ Git repository:
  +
  ----
      $ git init

diff --cc Documentation/git-stripspace.txt
Simple merge

diff --cc Documentation/githooks.txt
Simple merge

diff --cc Documentation/gitignore.txt
Simple merge

diff --cc Documentation/howto/maintain-git.txt
index 816c791502f99cdb2f2ca996e30d1b73cb95a6ac,86715735b34c5f92f786fd2f62dd44c6e8d7205b..33ae69c11f0f70b6dd1881f0ae013eca653acf5c
--- 1/Documentation/howto/maintain-git.txt
--- 2/Documentation/howto/maintain-git.txt
+++ b/Documentation/howto/maintain-git.txt
@@@ -10,12 -10,9 +10,12 @@@ Content-type: text/asciido
  How to maintain Git
  ===================
  
- The maintainer's git time is spent on three activities.
 +Activities
 +----------
 +
+ The maintainer's Git time is spent on three activities.
  
 - - Communication (60%)
 + - Communication (45%)
  
     Mailing list discussions on general design, fielding user
     questions, diagnosing bug reports; reviewing, commenting on,
@@@ -87,22 -77,14 +87,22 @@@ this mailing list after each feature re
     are found before new topics are merged to 'master'.
  
  
- A typical git day for the maintainer implements the above policy
 +A Typical Git Day
 +-----------------
 +
+ A typical Git day for the maintainer implements the above policy
  by doing the following:
  
 - - Scan mailing list and #git channel log.  Respond with review
 -   comments, suggestions etc.  Kibitz.  Collect potentially
 -   usable patches from the mailing list.  Patches about a single
 -   topic go to one mailbox (I read my mail in Gnus, and type
 -   \C-o to save/append messages in files in mbox format).
 + - Scan mailing list.  Respond with review comments, suggestions
 +   etc.  Kibitz.  Collect potentially usable patches from the
 +   mailing list.  Patches about a single topic go to one mailbox (I
 +   read my mail in Gnus, and type \C-o to save/append messages in
 +   files in mbox format).
 +
 + - Write his own patches to address issues raised on the list but
 +   nobody has stepped up solving.  Send it out just like other
 +   contributors do, and pick them up just like patches from other
 +   contributors (see above).
  
   - Review the patches in the saved mailboxes.  Edit proposed log
     message for typofixes and clarifications, and add Acks

diff --cc Documentation/technical/api-directory-listing.txt
Simple merge

diff --cc README
Simple merge