Documentation: avoid poor-man's small caps GIT

In the earlier days, we used to spell the name of the system as GIT,
to simulate as if it were typeset with capital G and IT in small
caps.  Later we stopped doing so at around 1.6.5 days.

Let's stop doing so throughout the documentation.  The name to refer
to the whole system (and the concept it embodies) is "Git"; the
command end-users type is "git".  And document this in the coding
guideline.

Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation/CodingGuidelines

@@ -230,3 +230,8 @@ Writing Documentation:
    valid usage.  "*" has its own pair of brackets, because it can
    (optionally) be specified only when one or more of the letters is
    also provided.
+
+  A note on notation:
+   Use 'git' (all lowercase) when talking about commands i.e. something
+   the user would type into a shell and use 'Git' (uppercase first letter)
+   when talking about the version control system and its properties.

Documentation/SubmittingPatches

@@ -206,7 +206,7 @@ patch.
 To improve tracking of who did what, we've borrowed the
 "sign-off" procedure from the Linux kernel project on patches
-that are being emailed around.  Although core GIT is a lot
+that are being emailed around.  Although core Git is a lot
 smaller project it is a good discipline to follow it.
 The sign-off is a simple line at the end of the explanation for

Documentation/asciidoc.conf

@@ -4,7 +4,7 @@
 #
 # Note, {0} is the manpage section, while {target} is the command.
 #
-# Show GIT link as: <command>(<section>); if section is defined, else just show
+# Show Git link as: <command>(<section>); if section is defined, else just show
 # the command.
 [macros]

Documentation/everyday.txt

-Everyday GIT With 20 Commands Or So
+Everyday Git With 20 Commands Or So
 ===================================
 <<Individual Developer (Standalone)>> commands are essential for
@@ -229,7 +229,7 @@ commands in addition to the ones needed by participants.
 Examples
 ~~~~~~~~
-My typical GIT day.::
+My typical Git day.::
 +
 ------------
 $ git status <1>

Documentation/git-clone.txt

@@ -125,7 +125,7 @@ objects from the source repository into a pack in the cloned repository.
 	No checkout of HEAD is performed after the clone is complete.
 --bare::
-	Make a 'bare' GIT repository.  That is, instead of
+	Make a 'bare' Git repository.  That is, instead of
 	creating `<directory>` and placing the administrative
 	files in `<directory>/.git`, make the `<directory>`
 	itself the `$GIT_DIR`. This obviously implies the `-n`

Documentation/git-cvsexportcommit.txt

@@ -15,7 +15,7 @@ SYNOPSIS
 DESCRIPTION
 -----------
-Exports a commit from GIT to a CVS checkout, making it easier
+Exports a commit from Git to a CVS checkout, making it easier
 to merge patches from a git repository into a CVS repository.
 Specify the name of a CVS checkout using the -w switch or execute it

Documentation/git-cvsserver.txt

@@ -72,9 +72,9 @@ plugin. Most functionality works fine with both of these clients.
 LIMITATIONS
 -----------
-CVS clients cannot tag, branch or perform GIT merges.
-'git-cvsserver' maps GIT branches to CVS modules. This is very different
+CVS clients cannot tag, branch or perform Git merges.
+'git-cvsserver' maps Git branches to CVS modules. This is very different
 from what most CVS users would expect since in CVS modules usually represent
 one or more directories.
@@ -130,7 +130,7 @@ Then provide your password via the pserver method, for example:
 ------
    cvs -d:pserver:someuser:somepassword <at> server/path/repo.git co <HEAD_name>
 ------
-No special setup is needed for SSH access, other than having GIT tools
+No special setup is needed for SSH access, other than having Git tools
 in the PATH. If you have clients that do not accept the CVS_SERVER
 environment variable, you can rename 'git-cvsserver' to `cvs`.
@@ -197,7 +197,7 @@ allowing access over SSH.
    shell is bash, .bashrc may be a reasonable alternative.
 5. Clients should now be able to check out the project. Use the CVS 'module'
-   name to indicate what GIT 'head' you want to check out.  This also sets the
+   name to indicate what Git 'head' you want to check out.  This also sets the
    name of your newly checked-out directory, unless you tell it otherwise with
    `-d <dir_name>`.  For example, this checks out 'master' branch to the
    `project-master` directory:

Documentation/git-daemon.txt

@@ -51,7 +51,7 @@ OPTIONS
 --base-path=<path>::
 	Remap all the path requests as relative to the given path.
-	This is sort of "GIT root" - if you run 'git daemon' with
+	This is sort of "Git root" - if you run 'git daemon' with
 	'--base-path=/srv/git' on example.com, then if you later try to pull
 	'git://example.com/hello.git', 'git daemon' will interpret the path
 	as '/srv/git/hello.git'.
@@ -73,7 +73,7 @@ OPTIONS
 	whitelist.
 --export-all::
-	Allow pulling from all directories that look like GIT repositories
+	Allow pulling from all directories that look like Git repositories
 	(have the 'objects' and 'refs' subdirectories), even if they
 	do not have the 'git-daemon-export-ok' file.

Documentation/git-mv.txt

@@ -34,7 +34,7 @@ OPTIONS
 -k::
         Skip move or rename actions which would lead to an error
 	condition. An error happens when a source is neither existing nor
-        controlled by GIT, or when it would overwrite an existing
+	controlled by Git, or when it would overwrite an existing
         file unless '-f' is given.
 -n::
 --dry-run::

Documentation/git-send-email.txt

@@ -67,7 +67,7 @@ The --cc option must be repeated for each user you want on the cc list.
 When '--compose' is used, git send-email will use the From, Subject, and
 In-Reply-To headers specified in the message. If the body of the message
 (what you type after the headers and a blank line) only contains blank
-(or GIT: prefixed) lines the summary won't be sent, but From, Subject,
+(or Git: prefixed) lines the summary won't be sent, but From, Subject,
 and In-Reply-To headers will be used unless they are removed.
 +
 Missing From or In-Reply-To headers will be prompted for.

Documentation/git-tools.txt

@@ -19,24 +19,24 @@ Alternative/Augmentative Porcelains
    Cogito is a version control system layered on top of the git tree history
    storage system. It aims at seamless user interface and ease of use,
-   providing generally smoother user experience than the "raw" Core GIT
+   providing generally smoother user experience than the "raw" Core Git
    itself and indeed many other version control systems.
    Cogito is no longer maintained as most of its functionality
-   is now in core GIT.
+   is now in core Git.
    - *pg* (http://www.spearce.org/category/projects/scm/pg/)
-   pg is a shell script wrapper around GIT to help the user manage a set of
+   pg is a shell script wrapper around Git to help the user manage a set of
    patches to files. pg is somewhat like quilt or StGIT, but it does have a
    slightly different feature set.
    - *StGit* (http://www.procode.org/stgit/)
-   Stacked GIT provides a quilt-like patch management functionality in the
-   GIT environment. You can easily manage your patches in the scope of GIT
+   Stacked Git provides a quilt-like patch management functionality in the
+   Git environment. You can easily manage your patches in the scope of Git
    until they get merged upstream.
@@ -45,7 +45,7 @@ History Viewers
    - *gitk* (shipped with git-core)
-   gitk is a simple Tk GUI for browsing history of GIT repositories easily.
+   gitk is a simple Tk GUI for browsing history of Git repositories easily.
    - *gitview*  (contrib/)
@@ -55,7 +55,7 @@ History Viewers
    - *gitweb* (shipped with git-core)
-   GITweb provides full-fledged web interface for GIT repositories.
+   Gitweb provides full-fledged web interface for Git repositories.
    - *qgit* (http://digilander.libero.it/mcostalba/)

Documentation/git-update-ref.txt

@@ -73,7 +73,7 @@ in ref value.  Log lines are formatted as:
 Where "oldsha1" is the 40 character hexadecimal value previously
 stored in <ref>, "newsha1" is the 40 character hexadecimal value of
 <newvalue> and "committer" is the committer's name, email address
-and date in the standard GIT committer ident format.
+and date in the standard Git committer ident format.
 Optionally with -m:

Documentation/git.txt

@@ -890,7 +890,7 @@ See also the link:howto-index.html[howto] documents for some useful
 examples.
 The internals are documented in the
-link:technical/api-index.html[GIT API documentation].
+link:technical/api-index.html[Git API documentation].
 Users migrating from CVS may also want to
 read linkgit:gitcvs-migration[7].

Documentation/gitcore-tutorial.txt

@@ -16,8 +16,8 @@ This tutorial explains how to use the "core" git commands to set up and
 work with a git repository.
 If you just need to use git as a revision control system you may prefer
-to start with "A Tutorial Introduction to GIT" (linkgit:gittutorial[7]) or
-link:user-manual.html[the GIT User Manual].
+to start with "A Tutorial Introduction to Git" (linkgit:gittutorial[7]) or
+link:user-manual.html[the Git User Manual].
 However, an understanding of these low-level tools can be helpful if
 you want to understand git's internals.

Documentation/gitglossary.txt

@@ -3,7 +3,7 @@ gitglossary(7)
 NAME
 ----
-gitglossary - A GIT Glossary
+gitglossary - A Git Glossary
 SYNOPSIS
 --------

Documentation/gittutorial.txt

@@ -656,7 +656,7 @@ digressions that may be interesting at this point are:
   * linkgit:gitworkflows[7]: Gives an overview of recommended
     workflows.
-  * link:everyday.html[Everyday GIT with 20 Commands Or So]
+  * link:everyday.html[Everyday Git with 20 Commands Or So]
   * linkgit:gitcvs-migration[7]: Git for CVS users.

Documentation/gitweb.txt

@@ -504,7 +504,7 @@ repositories, you can configure Apache like this:
 The above configuration expects your public repositories to live under
 '/pub/git' and will serve them as `http://git.domain.org/dir-under-pub-git`,
-both as cloneable GIT URL and as browseable gitweb interface.  If you then
+both as cloneable Git URL and as browseable gitweb interface.  If you then
 start your linkgit:git-daemon[1] with `--base-path=/pub/git --export-all`
 then you can even use the `git://` URL with exactly the same path.

Documentation/gitworkflows.txt

@@ -242,7 +242,7 @@ tag to the tip of 'master' indicating the release version:
 .Release tagging
 [caption="Recipe: "]
 =====================================
-`git tag -s -m "GIT X.Y.Z" vX.Y.Z master`
+`git tag -s -m "Git X.Y.Z" vX.Y.Z master`
 =====================================
 You need to push the new tag to a public git server (see

Documentation/glossary-content.txt

@@ -52,7 +52,7 @@
 [[def_cherry-picking]]cherry-picking::
 	In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of
 	changes out of a series of changes (typically commits) and record them
-	as a new series of changes on top of a different codebase. In GIT, this is
+	as a new series of changes on top of a different codebase. In Git, this is
 	performed by the "git cherry-pick" command to extract the change introduced
 	by an existing <<def_commit,commit>> and to record it based on the tip
 	of the current <<def_branch,branch>> as a new commit.

Documentation/howto-index.sh

 #!/bin/sh
 cat <<\EOF
-GIT Howto Index
+Git Howto Index
 ===============
 Here is a collection of mailing list postings made by various