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

Documentation/howto/maintain-git.txt

@@ -1,7 +1,7 @@
 From: Junio C Hamano <gitster@pobox.com>
 Date: Wed, 21 Nov 2007 16:32:55 -0800
 Subject: Addendum to "MaintNotes"
-Abstract: Imagine that git development is racing along as usual, when our friendly
+Abstract: Imagine that Git development is racing along as usual, when our friendly
  neighborhood maintainer is struck down by a wayward bus. Out of the
  hordes of suckers (loyal developers), you have been tricked (chosen) to
  step up as the new maintainer. This howto will show you "how to" do it.
@@ -13,7 +13,7 @@ How to maintain Git
 Activities
 ----------
 
-The maintainer's git time is spent on three activities.
+The maintainer's Git time is spent on three activities.
 
  - Communication (45%)
 
@@ -90,7 +90,7 @@ this mailing list after each feature release is made.
 A Typical Git Day
 -----------------
 
-A typical git day for the maintainer implements the above policy
+A typical Git day for the maintainer implements the above policy
 by doing the following:
 
  - Scan mailing list.  Respond with review comments, suggestions

Documentation/howto/new-command.txt

@@ -1,25 +1,25 @@
 From: Eric S. Raymond <esr@thyrsus.com>
 Abstract: This is how-to documentation for people who want to add extension
- commands to git.  It should be read alongside api-builtin.txt.
+ commands to Git.  It should be read alongside api-builtin.txt.
 Content-type: text/asciidoc
 
 How to integrate new subcommands
 ================================
 
 This is how-to documentation for people who want to add extension
-commands to git.  It should be read alongside api-builtin.txt.
+commands to Git.  It should be read alongside api-builtin.txt.
 
 Runtime environment
 -------------------
 
-git subcommands are standalone executables that live in the git exec
+Git subcommands are standalone executables that live in the Git exec
 path, normally /usr/lib/git-core.  The git executable itself is a
 thin wrapper that knows where the subcommands live, and runs them by
 passing command-line arguments to them.
 
-(If "git foo" is not found in the git exec path, the wrapper
+(If "git foo" is not found in the Git exec path, the wrapper
 will look in the rest of your $PATH for it.  Thus, it's possible
-to write local git extensions that don't live in system space.)
+to write local Git extensions that don't live in system space.)
 
 Implementation languages
 ------------------------
@@ -30,13 +30,13 @@ Perl.
 While we strongly encourage coding in portable C for portability,
 these specific scripting languages are also acceptable.  We won't
 accept more without a very strong technical case, as we don't want
-to broaden the git suite's required dependencies.  Import utilities,
+to broaden the Git suite's required dependencies.  Import utilities,
 surgical tools, remote helpers and other code at the edges of the
-git suite are more lenient and we allow Python (and even Tcl/tk),
+Git suite are more lenient and we allow Python (and even Tcl/tk),
 but they should not be used for core functions.
 
 This may change in the future.  Especially Python is not allowed in
-core because we need better Python integration in the git Windows
+core because we need better Python integration in the Git Windows
 installer before we can be confident people in that environment
 won't experience an unacceptably large loss of capability.
 
@@ -54,7 +54,7 @@ functions available to built-in commands written in C.
 What every extension command needs
 ----------------------------------
 
-You must have a man page, written in asciidoc (this is what git help
+You must have a man page, written in asciidoc (this is what Git help
 followed by your subcommand name will display).  Be aware that there is
 a local asciidoc configuration and macros which you should use.  It's
 often helpful to start by cloning an existing page and replacing the
@@ -74,7 +74,7 @@ Integrating a command
 ---------------------
 
 Here are the things you need to do when you want to merge a new
-subcommand into the git tree.
+subcommand into the Git tree.
 
 1. Don't forget to sign off your patch!
 

Documentation/howto/rebase-from-internal-branch.txt

@@ -4,7 +4,7 @@ Cc:	Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>
 Subject: Re: sending changesets from the middle of a git tree
 Date:	Sun, 14 Aug 2005 18:37:39 -0700
 Abstract: In this article, JC talks about how he rebases the
- public "pu" branch using the core GIT tools when he updates
+ public "pu" branch using the core Git tools when he updates
  the "master" branch, and how "rebase" works.  Also discussed
  is how this applies to individual developers who sends patches
  upstream.
@@ -31,7 +31,7 @@ up.  With its basing philosophical ancestry on quilt, this is
 the kind of task StGIT is designed to do.
 
 I just have done a simpler one, this time using only the core
-GIT tools.
+Git tools.
 
 I had a handful of commits that were ahead of master in pu, and I
 wanted to add some documentation bypassing my usual habit of
@@ -96,7 +96,7 @@ you ran fsck-cache, which is normal.  After testing "pu", you
 can run "git prune" to get rid of those original three commits.
 
 While I am talking about "git rebase", I should talk about how
-to do cherrypicking using only the core GIT tools.
+to do cherrypicking using only the core Git tools.
 
 Let's go back to the earlier picture, with different labels.
 

Documentation/howto/rebuild-from-update-hook.txt

@@ -3,7 +3,7 @@ Message-ID: <7vy86o6usx.fsf@assigned-by-dhcp.cox.net>
 From: Junio C Hamano <gitster@pobox.com>
 Date: Fri, 26 Aug 2005 18:19:10 -0700
 Abstract: In this how-to article, JC talks about how he
- uses the post-update hook to automate git documentation page
+ uses the post-update hook to automate Git documentation page
  shown at http://www.kernel.org/pub/software/scm/git/docs/.
 Content-type: text/asciidoc
 
@@ -15,11 +15,11 @@ are built from Documentation/ directory of the git.git project
 and needed to be kept up-to-date.  The www.kernel.org/ servers
 are mirrored and I was told that the origin of the mirror is on
 the machine $some.kernel.org, on which I was given an account
-when I took over git maintainership from Linus.
+when I took over Git maintainership from Linus.
 
 The directories relevant to this how-to are these two:
 
-    /pub/scm/git/git.git/	The public git repository.
+    /pub/scm/git/git.git/	The public Git repository.
     /pub/software/scm/git/docs/	The HTML documentation page.
 
 So I made a repository to generate the documentation under my
@@ -46,7 +46,7 @@ script:
     EOF
 
 Initially I used to run this by hand whenever I push into the
-public git repository.  Then I did a cron job that ran twice a
+public Git repository.  Then I did a cron job that ran twice a
 day.  The current round uses the post-update hook mechanism,
 like this:
 

Documentation/howto/recover-corrupted-blob-object.txt

@@ -20,7 +20,7 @@ itself doesn't actually tell you anything, in order to fix a corrupt
 object you basically have to find the "original source" for it.
 
 The easiest way to do that is almost always to have backups, and find the
-same object somewhere else. Backups really are a good idea, and git makes
+same object somewhere else. Backups really are a good idea, and Git makes
 it pretty easy (if nothing else, just clone the repository somewhere else,
 and make sure that you do *not* use a hard-linked clone, and preferably
 not the same disk/machine).
@@ -134,7 +134,7 @@ and your repository is good again!
 	git log --raw --all
 
 and just looked for the sha of the missing object (4b9458b..) in that
-whole thing. It's up to you - git does *have* a lot of information, it is
+whole thing. It's up to you - Git does *have* a lot of information, it is
 just missing one particular blob version.
 
 Trying to recreate trees and especially commits is *much* harder. So you

Documentation/howto/revert-a-faulty-merge.txt

@@ -164,7 +164,7 @@ merged. So it's debugging hell, because now you don't have lots of small
 changes that you can try to pinpoint which _part_ of it changes.
 
 But does it all work? Sure it does. You can revert a merge, and from a
-purely technical angle, git did it very naturally and had no real
+purely technical angle, Git did it very naturally and had no real
 troubles. It just considered it a change from "state before merge" to
 "state after merge", and that was it. Nothing complicated, nothing odd,
 nothing really dangerous. Git will do it without even thinking about it.

Documentation/howto/revert-branch-rebase.txt

@@ -12,10 +12,10 @@ How to revert an existing commit
 ================================
 
 One of the changes I pulled into the 'master' branch turns out to
-break building GIT with GCC 2.95.  While they were well intentioned
+break building Git with GCC 2.95.  While they were well intentioned
 portability fixes, keeping things working with gcc-2.95 was also
 important.  Here is what I did to revert the change in the 'master'
-branch and to adjust the 'pu' branch, using core GIT tools and
+branch and to adjust the 'pu' branch, using core Git tools and
 barebone Porcelain.
 
 First, prepare a throw-away branch in case I screw things up.

Documentation/howto/setup-git-server-over-http.txt

@@ -1,9 +1,9 @@
 From: Rutger Nijlunsing <rutger@nospam.com>
-Subject: Setting up a git repository which can be pushed into and pulled from over HTTP(S).
+Subject: Setting up a Git repository which can be pushed into and pulled from over HTTP(S).
 Date: Thu, 10 Aug 2006 22:00:26 +0200
 Content-type: text/asciidoc
 
-How to setup git server over http
+How to setup Git server over http
 =================================
 
 Since Apache is one of those packages people like to compile
@@ -44,20 +44,20 @@ What's needed:
 
 - have permissions to chown a directory
 
-- have git installed on the client, and
+- have Git installed on the client, and
 
-- either have git installed on the server or have a webdav client on
+- either have Git installed on the server or have a webdav client on
   the client.
 
 In effect, this means you're going to be root, or that you're using a
 preconfigured WebDAV server.
 
 
-Step 1: setup a bare GIT repository
+Step 1: setup a bare Git repository
 -----------------------------------
 
-At the time of writing, git-http-push cannot remotely create a GIT
-repository. So we have to do that at the server side with git. Another
+At the time of writing, git-http-push cannot remotely create a Git
+repository. So we have to do that at the server side with Git. Another
 option is to generate an empty bare repository at the client and copy
 it to the server with a WebDAV client (which is the only option if Git
 is not installed on the server).
@@ -189,7 +189,7 @@ http://<servername>/my-new-repo.git [x] Open as webfolder -> login .
 Step 3: setup the client
 ------------------------
 
-Make sure that you have HTTP support, i.e. your git was built with
+Make sure that you have HTTP support, i.e. your Git was built with
 libcurl (version more recent than 7.10). The command 'git http-push' with
 no argument should display a usage message.
 
@@ -268,7 +268,7 @@ Reading /usr/local/apache2/logs/error_log is often helpful.
 
   On Debian: Read /var/log/apache2/error.log instead.
 
-If you access HTTPS locations, git may fail verifying the SSL
+If you access HTTPS locations, Git may fail verifying the SSL
 certificate (this is return code 60). Setting http.sslVerify=false can
 help diagnosing the problem, but removes security checks.
 

Documentation/howto/use-git-daemon.txt

@@ -4,7 +4,7 @@ How to use git-daemon
 =====================
 
 Git can be run in inetd mode and in stand alone mode. But all you want is
-let a coworker pull from you, and therefore need to set up a git server
+let a coworker pull from you, and therefore need to set up a Git server
 real quick, right?
 
 Note that git-daemon is not really chatty at the moment, especially when

Documentation/howto/using-signed-tag-in-pull-request.txt

@@ -23,7 +23,7 @@ Earlier, a typical pull request may have started like this:
 
    Froboz 3.2 (2011-09-30 14:20:57 -0700)
 
- are available in the git repository at:
+ are available in the Git repository at:
 
    example.com:/git/froboz.git for-xyzzy
 ------------
@@ -107,7 +107,7 @@ The resulting msg.txt file begins like so:
 
    Froboz 3.2 (2011-09-30 14:20:57 -0700)
 
- are available in the git repository at:
+ are available in the Git repository at:
 
    example.com:/git/froboz.git tags/frotz-for-xyzzy