diff options
Diffstat (limited to 'Documentation/howto')
| -rw-r--r-- | Documentation/howto/maintain-git.txt | 6 | ||||
| -rw-r--r-- | Documentation/howto/new-command.txt | 20 | ||||
| -rw-r--r-- | Documentation/howto/rebase-from-internal-branch.txt | 6 | ||||
| -rw-r--r-- | Documentation/howto/rebuild-from-update-hook.txt | 8 | ||||
| -rw-r--r-- | Documentation/howto/recover-corrupted-blob-object.txt | 10 | ||||
| -rw-r--r-- | Documentation/howto/revert-a-faulty-merge.txt | 2 | ||||
| -rw-r--r-- | Documentation/howto/revert-branch-rebase.txt | 4 | ||||
| -rw-r--r-- | Documentation/howto/setup-git-server-over-http.txt | 18 | ||||
| -rw-r--r-- | Documentation/howto/use-git-daemon.txt | 2 | ||||
| -rw-r--r-- | Documentation/howto/using-signed-tag-in-pull-request.txt | 4 |
10 files changed, 40 insertions, 40 deletions
diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt index 816c791502..33ae69c11f 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. @@ -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 diff --git a/Documentation/howto/new-command.txt b/Documentation/howto/new-command.txt index 36502f6718..2abc3a0a0e 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/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt index 4627ee47f2..19ab604f1f 100644 --- a/Documentation/howto/rebase-from-internal-branch.txt +++ b/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. diff --git a/Documentation/howto/rebuild-from-update-hook.txt b/Documentation/howto/rebuild-from-update-hook.txt index 00c1b45b79..25378f68d3 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 7484735320..1b3b188d3c 100644 --- a/Documentation/howto/recover-corrupted-blob-object.txt +++ b/Documentation/howto/recover-corrupted-blob-object.txt @@ -15,12 +15,12 @@ On Fri, 9 Nov 2007, Yossi Leybovich wrote: > Any one know how can I track this object and understand which file is it ----------------------------------------------------------- -So exactly *because* the SHA1 hash is cryptographically secure, the hash +So exactly *because* the SHA-1 hash is cryptographically secure, the hash 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). @@ -44,7 +44,7 @@ So: ----------------------------------------------------------- This is the right thing to do, although it's usually best to save it under -it's full SHA1 name (you just dropped the "4b" from the result ;). +it's full SHA-1 name (you just dropped the "4b" from the result ;). Let's see what that tells us: @@ -89,7 +89,7 @@ working tree, in which case fixing this problem is really simple, just do git hash-object -w my-magic-file -again, and if it outputs the missing SHA1 (4b945..) you're now all done! +again, and if it outputs the missing SHA-1 (4b945..) you're now all done! But that's the really lucky case, so let's assume that it was some older version that was broken. How do you tell which version it was? @@ -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 8a685483f4..075418eeeb 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/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt index a59ced8d04..84dd839db4 100644 --- a/Documentation/howto/revert-branch-rebase.txt +++ b/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. diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt index a695f01f0e..7f4943e102 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,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. diff --git a/Documentation/howto/use-git-daemon.txt b/Documentation/howto/use-git-daemon.txt index 23cdf35435..7af2e52cf3 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 00f693bde8..bbf040eda8 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 |