summaryrefslogtreecommitdiff
path: root/Documentation/howto
diff options
context:
space:
mode:
authorThomas Ackermann <th.acker@arcor.de>2013-01-21 19:17:53 (GMT)
committerJunio C Hamano <gitster@pobox.com>2013-02-01 21:53:33 (GMT)
commit2de9b71138171dca7279db3b3fe67e868c76d921 (patch)
tree09cc74f510322f4f1241cd11a374490bc32d5aa3 /Documentation/howto
parent48a8c26c625a4d3631c4f614bceb38933e741408 (diff)
downloadgit-2de9b71138171dca7279db3b3fe67e868c76d921.zip
git-2de9b71138171dca7279db3b3fe67e868c76d921.tar.gz
git-2de9b71138171dca7279db3b3fe67e868c76d921.tar.bz2
Documentation: the name of the system is 'Git', not 'git'
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'Documentation/howto')
-rw-r--r--Documentation/howto/maintain-git.txt6
-rw-r--r--Documentation/howto/new-command.txt20
-rw-r--r--Documentation/howto/rebuild-from-update-hook.txt8
-rw-r--r--Documentation/howto/recover-corrupted-blob-object.txt4
-rw-r--r--Documentation/howto/revert-a-faulty-merge.txt2
-rw-r--r--Documentation/howto/setup-git-server-over-http.txt14
-rw-r--r--Documentation/howto/use-git-daemon.txt2
-rw-r--r--Documentation/howto/using-signed-tag-in-pull-request.txt4
8 files changed, 30 insertions, 30 deletions
diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt
index ea6e4a5..8671573 100644
--- a/Documentation/howto/maintain-git.txt
+++ b/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.
@@ -10,7 +10,7 @@ Content-type: text/asciidoc
How to maintain Git
===================
-The maintainer's git time is spent on three activities.
+The maintainer's Git time is spent on three activities.
- Communication (60%)
@@ -77,7 +77,7 @@ The policy.
are found before new topics are merged to 'master'.
-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 and #git channel log. Respond with review
diff --git a/Documentation/howto/new-command.txt b/Documentation/howto/new-command.txt
index 36502f6..2abc3a0 100644
--- a/Documentation/howto/new-command.txt
+++ b/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!
diff --git a/Documentation/howto/rebuild-from-update-hook.txt b/Documentation/howto/rebuild-from-update-hook.txt
index 00c1b45..25378f6 100644
--- a/Documentation/howto/rebuild-from-update-hook.txt
+++ b/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:
diff --git a/Documentation/howto/recover-corrupted-blob-object.txt b/Documentation/howto/recover-corrupted-blob-object.txt
index 7484735..6d362ce 100644
--- a/Documentation/howto/recover-corrupted-blob-object.txt
+++ b/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
diff --git a/Documentation/howto/revert-a-faulty-merge.txt b/Documentation/howto/revert-a-faulty-merge.txt
index 8a68548..075418e 100644
--- a/Documentation/howto/revert-a-faulty-merge.txt
+++ b/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.
diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt
index e49d785..7f4943e 100644
--- a/Documentation/howto/setup-git-server-over-http.txt
+++ b/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,9 +44,9 @@ 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
@@ -57,7 +57,7 @@ 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
+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.
diff --git a/Documentation/howto/use-git-daemon.txt b/Documentation/howto/use-git-daemon.txt
index 23cdf35..7af2e52 100644
--- a/Documentation/howto/use-git-daemon.txt
+++ b/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
diff --git a/Documentation/howto/using-signed-tag-in-pull-request.txt b/Documentation/howto/using-signed-tag-in-pull-request.txt
index 00f693b..bbf040e 100644
--- a/Documentation/howto/using-signed-tag-in-pull-request.txt
+++ b/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