@matheusbsbs / matheus-bagliano / commits / 2de9b71138

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>

Thomas Ackermann committed Jan 21, 2013 at 20:17 UTC 2de9b71138171dca7279db3b3fe67e868c76d921

128 files changed +902 -902

Documentation/CodingGuidelines

+7 -7

@@ -1,5 +1,5 @@

1 Like other projects, we also have some guidelines to keep to the

2 -code. For git in general, three rough rules are:

2 +code. For Git in general, three rough rules are:

4 - Most importantly, we never say "It's in POSIX; we'll happily

5 ignore your needs should your system not conform to it."

@@ -22,7 +22,7 @@ code. For git in general, three rough rules are:

22 As for more concrete guidelines, just imitate the existing code

23 (this is a good guideline, no matter which project you are

24 contributing to). It is always preferable to match the _local_

25 -convention. New code added to git suite is expected to match

25 +convention. New code added to Git suite is expected to match

26 the overall style of existing code. Modifications to existing

27 code is expected to match the style the surrounding code already

28 uses (even if it doesn't match the overall style of existing code).

@@ -112,7 +112,7 @@ For C programs:

112

113 - We try to keep to at most 80 characters per line.

114

115 - - We try to support a wide range of C compilers to compile git with,

115 + - We try to support a wide range of C compilers to compile Git with,

116 including old ones. That means that you should not use C99

117 initializers, even if a lot of compilers grok it.

118

@@ -164,14 +164,14 @@ For C programs:

164

165 - If you are planning a new command, consider writing it in shell

166 or perl first, so that changes in semantics can be easily

167 - changed and discussed. Many git commands started out like

167 + changed and discussed. Many Git commands started out like

168 that, and a few are still scripts.

169

170 - - Avoid introducing a new dependency into git. This means you

170 + - Avoid introducing a new dependency into Git. This means you

171 usually should stay away from scripting languages not already

172 - used in the git core command set (unless your command is clearly

172 + used in the Git core command set (unless your command is clearly

173 separate from it, such as an importer to convert random-scm-X

174 - repositories to git).

174 + repositories to Git).

175

176 - When we pass <string, length> pair to functions, we should try to

177 pass them in that order.

Documentation/Makefile

+2 -2

@@ -346,8 +346,8 @@ $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt

346 install-webdoc : html

347 '$(SHELL_PATH_SQ)' ./install-webdoc.sh $(WEBDOC_DEST)

348

349 -# You must have a clone of git-htmldocs and git-manpages repositories

350 -# next to the git repository itself for the following to work.

349 +# You must have a clone of 'git-htmldocs' and 'git-manpages' repositories

350 +# next to the 'git' repository itself for the following to work.

351

352 quick-install: quick-install-man

353

Documentation/SubmittingPatches

+5 -5

@@ -103,9 +103,9 @@ without external resources. Instead of giving a URL to a mailing list

103 archive, summarize the relevant points of the discussion.

104

105

106 -(3) Generate your patch using git tools out of your commits.

106 +(3) Generate your patch using Git tools out of your commits.

107

108 -git based diff tools generate unidiff which is the preferred format.

108 +Git based diff tools generate unidiff which is the preferred format.

109

110 You do not have to be afraid to use -M option to "git diff" or

111 "git format-patch", if your patch involves file renames. The

@@ -122,7 +122,7 @@ that is fine, but please mark it as such.

122

123 (4) Sending your patches.

124

125 -People on the git mailing list need to be able to read and

125 +People on the Git mailing list need to be able to read and

126 comment on the changes you are submitting. It is important for

127 a developer to be able to "quote" your changes, using standard

128 e-mail tools, so that they may comment on specific portions of

@@ -244,7 +244,7 @@ then you just add a line saying

244

245 Signed-off-by: Random J Developer <random@developer.example.org>

246

247 -This line can be automatically added by git if you run the git-commit

247 +This line can be automatically added by Git if you run the git-commit

248 command with the -s option.

249

250 Notice that you can place your own Signed-off-by: line when

@@ -337,7 +337,7 @@ Know the status of your patch after submission

337 tell you if your patch is merged in pu if you rebase on top of

338 master).

339

340 -* Read the git mailing list, the maintainer regularly posts messages

340 +* Read the Git mailing list, the maintainer regularly posts messages

341 entitled "What's cooking in git.git" and "What's in git.git" giving

342 the status of various proposed changes.

343

Documentation/blame-options.txt

+2 -2

@@ -95,7 +95,7 @@ of lines before or after the line given by <start>.

95 running extra passes of inspection.

96 +

97 <num> is optional but it is the lower bound on the number of

98 -alphanumeric characters that git must detect as moving/copying

98 +alphanumeric characters that Git must detect as moving/copying

99 within a file for it to associate those lines with the parent

100 commit. The default value is 20.

101

@@ -110,7 +110,7 @@ commit. The default value is 20.

110 looks for copies from other files in any commit.

111 +

112 <num> is optional but it is the lower bound on the number of

113 -alphanumeric characters that git must detect as moving/copying

113 +alphanumeric characters that Git must detect as moving/copying

114 between files for it to associate those lines with the parent

115 commit. And the default value is 40. If there are more than one

116 `-C` options given, the <num> argument of the last `-C` will

Documentation/config.txt

+56 -56

@@ -1,14 +1,14 @@

1 CONFIGURATION FILE

2 ------------------

4 -The git configuration file contains a number of variables that affect

5 -the git command's behavior. The `.git/config` file in each repository

4 +The Git configuration file contains a number of variables that affect

5 +the Git commands' behavior. The `.git/config` file in each repository

6 is used to store the configuration for that repository, and

7 `$HOME/.gitconfig` is used to store a per-user configuration as

8 fallback values for the `.git/config` file. The file `/etc/gitconfig`

9 can be used to store a system-wide default configuration.

11 -The configuration variables are used by both the git plumbing

11 +The configuration variables are used by both the Git plumbing

12 and the porcelains. The variables are divided into sections, wherein

13 the fully qualified variable name of the variable itself is the last

14 dot-separated segment and the section name is everything before the last

@@ -209,9 +209,9 @@ core.ignoreCygwinFSTricks::

209

210 core.ignorecase::

211 If true, this option enables various workarounds to enable

212 - git to work better on filesystems that are not case sensitive,

212 + Git to work better on filesystems that are not case sensitive,

213 like FAT. For example, if a directory listing finds

214 - "makefile" when git expects "Makefile", git will assume

214 + "makefile" when Git expects "Makefile", Git will assume

215 it is really the same file, and continue to remember it as

216 "Makefile".

217 +

@@ -220,13 +220,13 @@ will probe and set core.ignorecase true if appropriate when the repository

220 is created.

221

222 core.precomposeunicode::

223 - This option is only used by Mac OS implementation of git.

224 - When core.precomposeunicode=true, git reverts the unicode decomposition

223 + This option is only used by Mac OS implementation of Git.

224 + When core.precomposeunicode=true, Git reverts the unicode decomposition

225 of filenames done by Mac OS. This is useful when sharing a repository

226 between Mac OS and Linux or Windows.

227 - (Git for Windows 1.7.10 or higher is needed, or git under cygwin 1.7).

228 - When false, file names are handled fully transparent by git,

229 - which is backward compatible with older versions of git.

227 + (Git for Windows 1.7.10 or higher is needed, or Git under cygwin 1.7).

228 + When false, file names are handled fully transparent by Git,

229 + which is backward compatible with older versions of Git.

230

231 core.trustctime::

232 If false, the ctime differences between the index and the

@@ -256,20 +256,20 @@ core.eol::

256 conversion.

257

258 core.safecrlf::

259 - If true, makes git check if converting `CRLF` is reversible when

259 + If true, makes Git check if converting `CRLF` is reversible when

260 end-of-line conversion is active. Git will verify if a command

261 modifies a file in the work tree either directly or indirectly.

262 For example, committing a file followed by checking out the

263 same file should yield the original file in the work tree. If

264 this is not the case for the current setting of

265 - `core.autocrlf`, git will reject the file. The variable can

266 - be set to "warn", in which case git will only warn about an

265 + `core.autocrlf`, Git will reject the file. The variable can

266 + be set to "warn", in which case Git will only warn about an

267 irreversible conversion but continue the operation.

268 +

269 CRLF conversion bears a slight chance of corrupting data.

270 -When it is enabled, git will convert CRLF to LF during commit and LF to

270 +When it is enabled, Git will convert CRLF to LF during commit and LF to

271 CRLF during checkout. A file that contains a mixture of LF and

272 -CRLF before the commit cannot be recreated by git. For text

272 +CRLF before the commit cannot be recreated by Git. For text

273 files this is the right thing to do: it corrects line endings

274 such that we have only LF line endings in the repository.

275 But for binary files that are accidentally classified as text the

@@ -279,7 +279,7 @@ If you recognize such corruption early you can easily fix it by

279 setting the conversion type explicitly in .gitattributes. Right

280 after committing you still have the original file in your work

281 tree and this file is not yet corrupted. You can explicitly tell

282 -git that this file is binary and git will handle the file

282 +Git that this file is binary and Git will handle the file

283 appropriately.

284 +

285 Unfortunately, the desired effect of cleaning up text files with

@@ -324,7 +324,7 @@ is created.

324 core.gitProxy::

325 A "proxy command" to execute (as 'command host port') instead

326 of establishing direct connection to the remote server when

327 - using the git protocol for fetching. If the variable value is

327 + using the Git protocol for fetching. If the variable value is

328 in the "COMMAND for DOMAIN" format, the command is applied only

329 on hostnames ending with the specified domain string. This variable

330 may be set multiple times and is matched in the given order;

@@ -383,7 +383,7 @@ Note that this variable is honored even when set in a configuration

383 file in a ".git" subdirectory of a directory and its value differs

384 from the latter directory (e.g. "/path/to/.git/config" has

385 core.worktree set to "/different/path"), which is most likely a

386 -misconfiguration. Running git commands in the "/path/to" directory will

386 +misconfiguration. Running Git commands in the "/path/to" directory will

387 still use "/different/path" as the root of the work tree and can cause

388 confusion unless you know what you are doing (e.g. you are creating a

389 read-only snapshot of the same index to a location different from the

@@ -415,7 +415,7 @@ core.sharedRepository::

415 several users in a group (making sure all the files and objects are

416 group-writable). When 'all' (or 'world' or 'everybody'), the

417 repository will be readable by all users, additionally to being

418 - group-shareable. When 'umask' (or 'false'), git will use permissions

418 + group-shareable. When 'umask' (or 'false'), Git will use permissions

419 reported by umask(2). When '0xxx', where '0xxx' is an octal number,

420 files in the repository will have this mode value. '0xxx' will override

421 user's umask value (whereas the other options will only override

@@ -426,7 +426,7 @@ core.sharedRepository::

426 See linkgit:git-init[1]. False by default.

427

428 core.warnAmbiguousRefs::

429 - If true, git will warn you if the ref name you passed it is ambiguous

429 + If true, Git will warn you if the ref name you passed it is ambiguous

430 and might match multiple refs in the .git/refs/ tree. True by default.

431

432 core.compression::

@@ -498,7 +498,7 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.

498

499 core.excludesfile::

500 In addition to '.gitignore' (per-directory) and

501 - '.git/info/exclude', git looks into this file for patterns

501 + '.git/info/exclude', Git looks into this file for patterns

502 of files which are not meant to be tracked. "`~/`" is expanded

503 to the value of `$HOME` and "`~user/`" to the specified user's

504 home directory. Its default value is $XDG_CONFIG_HOME/git/ignore.

@@ -516,7 +516,7 @@ core.askpass::

516

517 core.attributesfile::

518 In addition to '.gitattributes' (per-directory) and

519 - '.git/info/attributes', git looks into this file for attributes

519 + '.git/info/attributes', Git looks into this file for attributes

520 (see linkgit:gitattributes[5]). Path expansions are made the same

521 way as for `core.excludesfile`. Its default value is

522 $XDG_CONFIG_HOME/git/attributes. If $XDG_CONFIG_HOME is either not

@@ -535,9 +535,9 @@ sequence.editor::

535 When not configured the default commit message editor is used instead.

536

537 core.pager::

538 - The command that git will use to paginate output. Can

538 + The command that Git will use to paginate output. Can

539 be overridden with the `GIT_PAGER` environment

540 - variable. Note that git sets the `LESS` environment

540 + variable. Note that Git sets the `LESS` environment

541 variable to `FRSX` if it is unset when it runs the

542 pager. One can change these settings by setting the

543 `LESS` variable to some other value. Alternately,

@@ -545,11 +545,11 @@ core.pager::

545 global basis by setting the `core.pager` option.

546 Setting `core.pager` has no effect on the `LESS`

547 environment variable behaviour above, so if you want

548 - to override git's default settings this way, you need

548 + to override Git's default settings this way, you need

549 to be explicit. For example, to disable the S option

550 in a backward compatible manner, set `core.pager`

551 to `less -+S`. This will be passed to the shell by

552 - git, which will translate the final command to

552 + Git, which will translate the final command to

553 `LESS=FRSX less -+S`.

554

555 core.whitespace::

@@ -578,7 +578,7 @@ core.whitespace::

578 does not trigger if the character before such a carriage-return

579 is not a whitespace (not enabled by default).

580 * `tabwidth=<n>` tells how many character positions a tab occupies; this

581 - is relevant for `indent-with-non-tab` and when git fixes `tab-in-indent`

581 + is relevant for `indent-with-non-tab` and when Git fixes `tab-in-indent`

582 errors. The default tab width is 8. Allowed values are 1 to 63.

583

584 core.fsyncobjectfiles::

@@ -594,7 +594,7 @@ core.preloadindex::

594 +

595 This can speed up operations like 'git diff' and 'git status' especially

596 on filesystems like NFS that have weak caching semantics and thus

597 -relatively high IO latencies. With this set to 'true', git will do the

597 +relatively high IO latencies. With this set to 'true', Git will do the

598 index comparison to the filesystem data in parallel, allowing

599 overlapping IO's.

600

@@ -630,9 +630,9 @@ add.ignore-errors::

630 add.ignoreErrors::

631 Tells 'git add' to continue adding files when some files cannot be

632 added due to indexing errors. Equivalent to the '--ignore-errors'

633 - option of linkgit:git-add[1]. Older versions of git accept only

633 + option of linkgit:git-add[1]. Older versions of Git accept only

634 `add.ignore-errors`, which does not follow the usual naming

635 - convention for configuration variables. Newer versions of git

635 + convention for configuration variables. Newer versions of Git

636 honor `add.ignoreErrors` as well.

637

638 alias.*::

@@ -640,7 +640,7 @@ alias.*::

640 after defining "alias.last = cat-file commit HEAD", the invocation

641 "git last" is equivalent to "git cat-file commit HEAD". To avoid

642 confusion and troubles with script usage, aliases that

643 - hide existing git commands are ignored. Arguments are split by

643 + hide existing Git commands are ignored. Arguments are split by

644 spaces, the usual shell quoting and escaping is supported.

645 quote pair and a backslash can be used to quote them.

646 +

@@ -687,7 +687,7 @@ branch.autosetupmerge::

687

688 branch.autosetuprebase::

689 When a new branch is created with 'git branch' or 'git checkout'

690 - that tracks another branch, this variable tells git to set

690 + that tracks another branch, this variable tells Git to set

691 up pull to rebase instead of merge (see "branch.<name>.rebase").

692 When `never`, rebase is never automatically set to true.

693 When `local`, rebase is set to true for tracked branches of

@@ -868,7 +868,7 @@ color.status.<slot>::

868 one of `header` (the header text of the status message),

869 `added` or `updated` (files which are added but not committed),

870 `changed` (files which are changed but not added in the index),

871 - `untracked` (files which are not tracked by git),

871 + `untracked` (files which are not tracked by Git),

872 `branch` (the current branch), or

873 `nobranch` (the color the 'no branch' warning is shown in, defaulting

874 to red). The values of these variables may be specified as in

@@ -882,7 +882,7 @@ color.ui::

882 to `always` if you want all output not intended for machine

883 consumption to use color, to `true` or `auto` if you want such

884 output to use color when written to the terminal, or to `false` or

885 - `never` if you prefer git commands not to use color unless enabled

885 + `never` if you prefer Git commands not to use color unless enabled

886 explicitly with some other configuration or the `--color` option.

887

888 column.ui::

@@ -999,7 +999,7 @@ fetch.fsckObjects::

999 is used instead.

1000

1001 fetch.unpackLimit::

1002 - If the number of objects fetched over the git native

1002 + If the number of objects fetched over the Git native

1003 transfer is below this

1004 limit, then the objects will be unpacked into loose object

1005 files. However if the number of received objects equals or

@@ -1039,7 +1039,7 @@ format.subjectprefix::

1039

1040 format.signature::

1041 The default for format-patch is to output a signature containing

1042 - the git version number. Use this variable to change that default.

1042 + the Git version number. Use this variable to change that default.

1043 Set this variable to the empty string ("") to suppress

1044 signature generation.

1045

@@ -1152,7 +1152,7 @@ gitcvs.logfile::

1152 gitcvs.usecrlfattr::

1153 If true, the server will look up the end-of-line conversion

1154 attributes for files to determine the '-k' modes to use. If

1155 - the attributes force git to treat a file as text,

1155 + the attributes force Git to treat a file as text,

1156 the '-k' mode will be left blank so CVS clients will

1157 treat it as text. If they suppress text conversion, the file

1158 will be set with '-kb' mode, which suppresses any newline munging

@@ -1172,7 +1172,7 @@ gitcvs.allbinary::

1172

1173 gitcvs.dbname::

1174 Database used by git-cvsserver to cache revision information

1175 - derived from the git repository. The exact meaning depends on the

1175 + derived from the Git repository. The exact meaning depends on the

1176 used database driver, for SQLite (which is the default driver) this

1177 is a filename. Supports variable substitution (see

1178 linkgit:git-cvsserver[1] for details). May not contain semicolons (`;`).

@@ -1384,7 +1384,7 @@ http.proxy::

1384

1385 http.cookiefile::

1386 File containing previously stored cookie lines which should be used

1387 - in the git http session, if they match the server. The file format

1387 + in the Git http session, if they match the server. The file format

1388 of the file to read cookies from should be plain HTTP headers or

1389 the Netscape/Mozilla cookie file format (see linkgit:curl[1]).

1390 NOTE that the file specified with http.cookiefile is only used as

@@ -1406,7 +1406,7 @@ http.sslKey::

1406 variable.

1407

1408 http.sslCertPasswordProtected::

1409 - Enable git's password prompt for the SSL certificate. Otherwise

1409 + Enable Git's password prompt for the SSL certificate. Otherwise

1410 OpenSSL will prompt the user, possibly many times, if the

1411 certificate or private key is encrypted. Can be overridden by the

1412 'GIT_SSL_CERT_PASSWORD_PROTECTED' environment variable.

@@ -1453,7 +1453,7 @@ http.noEPSV::

1453

1454 http.useragent::

1455 The HTTP USER_AGENT string presented to an HTTP server. The default

1456 - value represents the version of the client git such as git/1.7.1.

1456 + value represents the version of the client Git such as git/1.7.1.

1457 This option allows you to override this value to a more common value

1458 such as Mozilla/4.0. This may be necessary, for instance, if

1459 connecting through a firewall that restricts HTTP connections to a set

@@ -1461,7 +1461,7 @@ http.useragent::

1461 Can be overridden by the 'GIT_HTTP_USER_AGENT' environment variable.

1462

1463 i18n.commitEncoding::

1464 - Character encoding the commit messages are stored in; git itself

1464 + Character encoding the commit messages are stored in; Git itself

1465 does not care per se, but this information is necessary e.g. when

1466 importing commits from emails or in the gitk graphical history

1467 browser (and possibly at other places in the future or in other

@@ -1599,7 +1599,7 @@ mergetool.keepBackup::

1599 `true` (i.e. keep the backup files).

1600

1601 mergetool.keepTemporaries::

1602 - When invoking a custom merge tool, git uses a set of temporary

1602 + When invoking a custom merge tool, Git uses a set of temporary

1603 files to pass to the tool. If the tool returns an error and this

1604 variable is set to `true`, then these temporary files will be

1605 preserved, otherwise they will be removed after the tool has

@@ -1627,7 +1627,7 @@ displayed.

1627

1628 notes.rewrite.<command>::

1629 When rewriting commits with <command> (currently `amend` or

1630 - `rebase`) and this variable is set to `true`, git

1630 + `rebase`) and this variable is set to `true`, Git

1631 automatically copies your notes from the original to the

1632 rewritten commit. Defaults to `true`, but see

1633 "notes.rewriteRef" below.

@@ -1707,7 +1707,7 @@ pack.threads::

1707 warning. This is meant to reduce packing time on multiprocessor

1708 machines. The required amount of memory for the delta search window

1709 is however multiplied by the number of threads.

1710 - Specifying 0 will cause git to auto-detect the number of CPU's

1710 + Specifying 0 will cause Git to auto-detect the number of CPU's

1711 and set the number of threads accordingly.

1712

1713 pack.indexVersion::

@@ -1719,11 +1719,11 @@ pack.indexVersion::

1719 and this config option ignored whenever the corresponding pack is

1720 larger than 2 GB.

1721 +

1722 -If you have an old git that does not understand the version 2 `*.idx` file,

1722 +If you have an old Git that does not understand the version 2 `*.idx` file,

1723 cloning or fetching over a non native protocol (e.g. "http" and "rsync")

1724 that will copy both `*.pack` file and corresponding `*.idx` file from the

1725 other side may give you a repository that cannot be accessed with your

1726 -older version of git. If the `*.pack` file is smaller than 2 GB, however,

1726 +older version of Git. If the `*.pack` file is smaller than 2 GB, however,

1727 you can use linkgit:git-index-pack[1] on the *.pack file to regenerate

1728 the `*.idx` file.

1729

@@ -1738,7 +1738,7 @@ pack.packSizeLimit::

1738

1739 pager.<cmd>::

1740 If the value is boolean, turns on or off pagination of the

1741 - output of a particular git subcommand when writing to a tty.

1741 + output of a particular Git subcommand when writing to a tty.

1742 Otherwise, turns on pagination for the subcommand using the

1743 pager specified by the value of `pager.<cmd>`. If `--paginate`

1744 or `--no-pager` is specified on the command line, it takes

@@ -1773,7 +1773,7 @@ pull.twohead::

1773 The default merge strategy to use when pulling a single branch.

1774

1775 push.default::

1776 - Defines the action git push should take if no refspec is given

1776 + Defines the action `git push` should take if no refspec is given

1777 on the command line, no refspec is configured in the remote, and

1778 no refspec is implied by any of the options given on the command

1779 line. Possible values are:

@@ -1913,7 +1913,7 @@ remote.<name>.tagopt::

1913 linkgit:git-fetch[1].

1914

1915 remote.<name>.vcs::

1916 - Setting this to a value <vcs> will cause git to interact with

1916 + Setting this to a value <vcs> will cause Git to interact with

1917 the remote with the git-remote-<vcs> helper.

1918

1919 remotes.<group>::

@@ -1923,9 +1923,9 @@ remotes.<group>::

1923 repack.usedeltabaseoffset::

1924 By default, linkgit:git-repack[1] creates packs that use

1925 delta-base offset. If you need to share your repository with

1926 - git older than version 1.4.4, either directly or via a dumb

1926 + Git older than version 1.4.4, either directly or via a dumb

1927 protocol such as http, then you need to set this option to

1928 - "false" and repack. Access from old git versions over the

1928 + "false" and repack. Access from old Git versions over the

1929 native protocol are unaffected by this option.

1930

1931 rerere.autoupdate::

@@ -1994,7 +1994,7 @@ showbranch.default::

1994 status.relativePaths::

1995 By default, linkgit:git-status[1] shows paths relative to the

1996 current directory. Setting this variable to `false` shows paths

1997 - relative to the repository root (this was the default for git

1997 + relative to the repository root (this was the default for Git

1998 prior to v1.5.4).

1999

2000 status.showUntrackedFiles::

@@ -2081,7 +2081,7 @@ url.<base>.insteadOf::

2081 large number of repositories, and serves them with multiple

2082 access methods, and some users need to use different access

2083 methods, this feature allows people to specify any of the

2084 - equivalent URLs and have git automatically rewrite the URL to

2084 + equivalent URLs and have Git automatically rewrite the URL to

2085 the best alternative for the particular user, even for a

2086 never-before-seen repository on the site. When more than one

2087 insteadOf strings match a given URL, the longest match is used.

@@ -2092,11 +2092,11 @@ url.<base>.pushInsteadOf::

2092 resulting URL will be pushed to. In cases where some site serves

2093 a large number of repositories, and serves them with multiple

2094 access methods, some of which do not allow push, this feature

2095 - allows people to specify a pull-only URL and have git

2095 + allows people to specify a pull-only URL and have Git

2096 automatically use an appropriate URL to push, even for a

2097 never-before-seen repository on the site. When more than one

2098 pushInsteadOf strings match a given URL, the longest match is

2099 - used. If a remote has an explicit pushurl, git will ignore this

2099 + used. If a remote has an explicit pushurl, Git will ignore this

2100 setting for that remote.

2101

2102 user.email::

Documentation/diff-config.txt

+1 -1

@@ -99,7 +99,7 @@ diff.renameLimit::

99 detection; equivalent to the 'git diff' option '-l'.

100

101 diff.renames::

102 - Tells git to detect renames. If set to any boolean value, it

102 + Tells Git to detect renames. If set to any boolean value, it

103 will enable basic rename detection. If set to "copies" or

104 "copy", it will detect copies, as well.

105

Documentation/diff-options.txt

+2 -2

@@ -283,7 +283,7 @@ few lines that happen to match textually as the context, but as a

283 single deletion of everything old followed by a single insertion of

284 everything new, and the number `m` controls this aspect of the -B

285 option (defaults to 60%). `-B/70%` specifies that less than 30% of the

286 -original should remain in the result for git to consider it a total

286 +original should remain in the result for Git to consider it a total

287 rewrite (i.e. otherwise the resulting patch will be a series of

288 deletion and insertion mixed together with context lines).

289 +

@@ -307,7 +307,7 @@ ifdef::git-log[]

307 endif::git-log[]

308 If `n` is specified, it is a threshold on the similarity

309 index (i.e. amount of addition/deletions compared to the

310 - file's size). For example, `-M90%` means git should consider a

310 + file's size). For example, `-M90%` means Git should consider a

311 delete/add pair to be a rename if more than 90% of the file

312 hasn't changed. Without a `%` sign, the number is to be read as

313 a fraction, with a decimal point before it. I.e., `-M5` becomes

Documentation/everyday.txt

+3 -3

@@ -12,7 +12,7 @@ commands in addition to the above.

13 <<Repository Administration>> commands are for system

14 administrators who are responsible for the care and feeding

15 -of git repositories.

15 +of Git repositories.

18 Individual Developer (Standalone)[[Individual Developer (Standalone)]]

@@ -87,7 +87,7 @@ $ git log v2.43.. curses/ <12>

87 +

88 <1> create a new topic branch.

89 <2> revert your botched changes in `curses/ux_audio_oss.c`.

90 -<3> you need to tell git if you added a new file; removal and

90 +<3> you need to tell Git if you added a new file; removal and

91 modification will be caught if you do `git commit -a` later.

92 <4> to see what changes you are committing.

93 <5> commit everything as you have tested, with your sign-off.

@@ -332,7 +332,7 @@ Run git-daemon to serve /pub/scm from xinetd.::

332 ------------

333 $ cat /etc/xinetd.d/git-daemon

334 # default: off

335 -# description: The git server offers access to git repositories

335 +# description: The Git server offers access to Git repositories

336 service git

337 {

338 disable = no

Documentation/git-apply.txt

+2 -2

@@ -24,7 +24,7 @@ Reads the supplied diff output (i.e. "a patch") and applies it to files.

24 With the `--index` option the patch is also applied to the index, and

25 with the `--cached` option the patch is only applied to the index.

26 Without these options, the command applies the patch only to files,

27 -and does not require them to be in a git repository.

27 +and does not require them to be in a Git repository.

29 This command applies the patch but does not create a commit. Use

30 linkgit:git-am[1] to create commits from patches generated by

@@ -198,7 +198,7 @@ behavior:

198 * `fix` outputs warnings for a few such errors, and applies the

199 patch after fixing them (`strip` is a synonym --- the tool

200 used to consider only trailing whitespace characters as errors, and the

201 - fix involved 'stripping' them, but modern gits do more).

201 + fix involved 'stripping' them, but modern Gits do more).

202 * `error` outputs warnings for a few such errors, and refuses

203 to apply the patch.

204 * `error-all` is similar to `error` but shows all errors.

Documentation/git-archimport.txt

+8 -8

@@ -3,7 +3,7 @@ git-archimport(1)

4 NAME

5 ----

6 -git-archimport - Import an Arch repository into git

6 +git-archimport - Import an Arch repository into Git

9 SYNOPSIS

@@ -40,13 +40,13 @@ directory. To follow the development of a project that uses Arch, rerun

40 incremental imports.

42 While 'git archimport' will try to create sensible branch names for the

43 -archives that it imports, it is also possible to specify git branch names

44 -manually. To do so, write a git branch name after each <archive/branch>

43 +archives that it imports, it is also possible to specify Git branch names

44 +manually. To do so, write a Git branch name after each <archive/branch>

45 parameter, separated by a colon. This way, you can shorten the Arch

46 -branch names and convert Arch jargon to git jargon, for example mapping a

46 +branch names and convert Arch jargon to Git jargon, for example mapping a

47 "PROJECT{litdd}devo{litdd}VERSION" branch to "master".

49 -Associating multiple Arch branches to one git branch is possible; the

49 +Associating multiple Arch branches to one Git branch is possible; the

50 result will make the most sense only if no commits are made to the first

51 branch, after the second branch is created. Still, this is useful to

52 convert Arch repositories that had been rotated periodically.

@@ -54,14 +54,14 @@ convert Arch repositories that had been rotated periodically.

55 MERGES

56 ------

57 -Patch merge data from Arch is used to mark merges in git as well. git

57 +Patch merge data from Arch is used to mark merges in Git as well. Git

58 does not care much about tracking patches, and only considers a merge when a

59 branch incorporates all the commits since the point they forked. The end result

60 -is that git will have a good idea of how far branches have diverged. So the

60 +is that Git will have a good idea of how far branches have diverged. So the

61 import process does lose some patch-trading metadata.

63 Fortunately, when you try and merge branches imported from Arch,

64 -git will find a good merge base, and it has a good chance of identifying

64 +Git will find a good merge base, and it has a good chance of identifying

65 patches that have been traded out-of-sequence between the branches.

67 OPTIONS

Documentation/git-archive.txt

+1 -1

@@ -128,7 +128,7 @@ export-ignore::

128 added to archive files. See linkgit:gitattributes[5] for details.

129

130 export-subst::

131 - If the attribute export-subst is set for a file then git will

131 + If the attribute export-subst is set for a file then Git will

132 expand several placeholders when adding this file to an archive.

133 See linkgit:gitattributes[5] for details.

134

Documentation/git-bisect-lk2009.txt

+11 -11

@@ -224,7 +224,7 @@ Note that the example that we will use is really a toy example, we

224 will be looking for the first commit that has a version like

225 "2.6.26-something", that is the commit that has a "SUBLEVEL = 26" line

226 in the top level Makefile. This is a toy example because there are

227 -better ways to find this commit with git than using "git bisect" (for

227 +better ways to find this commit with Git than using "git bisect" (for

228 example "git blame" or "git log -S<string>").

229

230 Driving a bisection manually

@@ -455,7 +455,7 @@ So only the W and B commits will be kept. Because commits X and Y will

455 have been removed by rules a) and b) respectively, and because commits

456 G are removed by rule b) too.

457

458 -Note for git users, that it is equivalent as keeping only the commit

458 +Note for Git users, that it is equivalent as keeping only the commit

459 given by:

460

461 -------------

@@ -710,8 +710,8 @@ Skip algorithm discussed

710 After step 7) (in the skip algorithm), we could check if the second

711 commit has been skipped and return it if it is not the case. And in

712 fact that was the algorithm we used from when "git bisect skip" was

713 -developed in git version 1.5.4 (released on February 1st 2008) until

714 -git version 1.6.4 (released July 29th 2009).

713 +developed in Git version 1.5.4 (released on February 1st 2008) until

714 +Git version 1.6.4 (released July 29th 2009).

715

716 But Ingo Molnar and H. Peter Anvin (another well known linux kernel

717 developer) both complained that sometimes the best bisection points

@@ -1025,10 +1025,10 @@ And here is what Andreas said about this work-flow <<5>>:

1025 _____________

1026 To give some hard figures, we used to have an average report-to-fix

1027 cycle of 142.6 hours (according to our somewhat weird bug-tracker

1028 -which just measures wall-clock time). Since we moved to git, we've

1028 +which just measures wall-clock time). Since we moved to Git, we've

1029 lowered that to 16.2 hours. Primarily because we can stay on top of

1030 the bug fixing now, and because everyone's jockeying to get to fix

1031 -bugs (we're quite proud of how lazy we are to let git find the bugs

1031 +bugs (we're quite proud of how lazy we are to let Git find the bugs

1032 for us). Each new release results in ~40% fewer bugs (almost certainly

1033 due to how we now feel about writing tests).

1034 _____________

@@ -1228,9 +1228,9 @@ commits in already released history, for example to change the commit

1228 message or the author. And it can also be used instead of git "grafts"

1229 to link a repository with another old repository.

1230

1231 -In fact it's this last feature that "sold" it to the git community, so

1232 -it is now in the "master" branch of git's git repository and it should

1233 -be released in git 1.6.5 in October or November 2009.

1231 +In fact it's this last feature that "sold" it to the Git community, so

1232 +it is now in the "master" branch of Git's Git repository and it should

1233 +be released in Git 1.6.5 in October or November 2009.

1234

1235 One problem with "git replace" is that currently it stores all the

1236 replacements refs in "refs/replace/", but it would be perhaps better

@@ -1324,7 +1324,7 @@ Acknowledgements

1324 ----------------

1325

1326 Many thanks to Junio Hamano for his help in reviewing this paper, for

1327 -reviewing the patches I sent to the git mailing list, for discussing

1327 +reviewing the patches I sent to the Git mailing list, for discussing

1328 some ideas and helping me improve them, for improving "git bisect" a

1329 lot and for his awesome work in maintaining and developing Git.

1330

@@ -1337,7 +1337,7 @@ Many thanks to Linus Torvalds for inventing, developing and

1337 evangelizing "git bisect", Git and Linux.

1338

1339 Many thanks to the many other great people who helped one way or

1340 -another when I worked on git, especially to Andreas Ericsson, Johannes

1340 +another when I worked on Git, especially to Andreas Ericsson, Johannes

1341 Schindelin, H. Peter Anvin, Daniel Barkalow, Bill Lear, John Hawley,

1342 Shawn O. Pierce, Jeff King, Sam Vilain, Jon Seymour.

1343

Documentation/git-bisect.txt

+2 -2

@@ -169,14 +169,14 @@ the revision as good or bad in the usual manner.

169 Bisect skip

170 ~~~~~~~~~~~~

171

172 -Instead of choosing by yourself a nearby commit, you can ask git

172 +Instead of choosing by yourself a nearby commit, you can ask Git

173 to do it for you by issuing the command:

174

175 ------------

176 $ git bisect skip # Current version cannot be tested

177 ------------

178

179 -But git may eventually be unable to tell the first bad commit among

179 +But Git may eventually be unable to tell the first bad commit among

180 a bad commit and one or more skipped commits.

181

182 You can even skip a range of commits, instead of just one commit,

Documentation/git-blame.txt

+1 -1

@@ -30,7 +30,7 @@ The report does not tell you anything about lines which have been deleted or

30 replaced; you need to use a tool such as 'git diff' or the "pickaxe"

31 interface briefly mentioned in the following paragraph.

33 -Apart from supporting file annotation, git also supports searching the

33 +Apart from supporting file annotation, Git also supports searching the

34 development history for when a code snippet occurred in a change. This makes it

35 possible to track when a code snippet was added to a file, moved or copied

36 between files, and eventually deleted or replaced. It works by searching for

Documentation/git-branch.txt

+1 -1

@@ -45,7 +45,7 @@ Note that this will create the new branch, but it will not switch the

45 working tree to it; use "git checkout <newbranch>" to switch to the

46 new branch.

48 -When a local branch is started off a remote-tracking branch, git sets up the

48 +When a local branch is started off a remote-tracking branch, Git sets up the

49 branch so that 'git pull' will appropriately merge from

50 the remote-tracking branch. This behavior may be changed via the global

51 `branch.autosetupmerge` configuration flag. That setting can be

Documentation/git-bundle.txt

+1 -1

@@ -19,7 +19,7 @@ DESCRIPTION

20 Some workflows require that one or more branches of development on one

21 machine be replicated on another machine, but the two machines cannot

22 -be directly connected, and therefore the interactive git protocols (git,

22 +be directly connected, and therefore the interactive Git protocols (git,

23 ssh, rsync, http) cannot be used. This command provides support for

24 'git fetch' and 'git pull' to operate by packaging objects and references

25 in an archive at the originating machine, then importing those into

Documentation/git-check-ref-format.txt

+2 -2

@@ -18,14 +18,14 @@ DESCRIPTION

18 Checks if a given 'refname' is acceptable, and exits with a non-zero

19 status if it is not.

21 -A reference is used in git to specify branches and tags. A

21 +A reference is used in Git to specify branches and tags. A

22 branch head is stored in the `refs/heads` hierarchy, while

23 a tag is stored in the `refs/tags` hierarchy of the ref namespace

24 (typically in `$GIT_DIR/refs/heads` and `$GIT_DIR/refs/tags`

25 directories or, as entries in file `$GIT_DIR/packed-refs`

26 if refs are packed by `git gc`).

28 -git imposes the following rules on how references are named:

28 +Git imposes the following rules on how references are named:

30 . They can include slash `/` for hierarchical (directory)

31 grouping, but no slash-separated component can begin with a

Documentation/git-checkout.txt

+2 -2

@@ -333,7 +333,7 @@ a---b---c---d branch 'master' (refers to commit 'd')

333 tag 'v2.0' (refers to commit 'b')

334 ------------

335

336 -In fact, we can perform all the normal git operations. But, let's look

336 +In fact, we can perform all the normal Git operations. But, let's look

337 at what happens when we then checkout master:

338

339 ------------

@@ -350,7 +350,7 @@ a---b---c---d branch 'master' (refers to commit 'd')

350

351 It is important to realize that at this point nothing refers to commit

352 'f'. Eventually commit 'f' (and by extension commit 'e') will be deleted

353 -by the routine git garbage collection process, unless we create a reference

353 +by the routine Git garbage collection process, unless we create a reference

354 before that happens. If we have not yet moved away from commit 'f',

355 any of these will create a reference to it:

356

Documentation/git-clean.txt

+4 -4

@@ -16,7 +16,7 @@ DESCRIPTION

16 Cleans the working tree by recursively removing files that are not

17 under version control, starting from the current directory.

19 -Normally, only files unknown to git are removed, but if the '-x'

19 +Normally, only files unknown to Git are removed, but if the '-x'

20 option is specified, ignored files are also removed. This can, for

21 example, be useful to remove all build products.

@@ -27,13 +27,13 @@ OPTIONS

27 -------

28 -d::

29 Remove untracked directories in addition to untracked files.

30 - If an untracked directory is managed by a different git

30 + If an untracked directory is managed by a different Git

31 repository, it is not removed by default. Use -f option twice

32 if you really want to remove such a directory.

34 -f::

35 --force::

36 - If the git configuration variable clean.requireForce is not set

36 + If the Git configuration variable clean.requireForce is not set

37 to false, 'git clean' will refuse to run unless given -f or -n.

39 -n::

@@ -60,7 +60,7 @@ OPTIONS

60 working directory to test a clean build.

62 -X::

63 - Remove only files ignored by git. This may be useful to rebuild

63 + Remove only files ignored by Git. This may be useful to rebuild

64 everything from scratch, but keep manually created files.

66 SEE ALSO

Documentation/git-clone.txt

+7 -7

@@ -43,7 +43,7 @@ OPTIONS

43 --local::

44 -l::

45 When the repository to clone from is on a local machine,

46 - this flag bypasses the normal "git aware" transport

46 + this flag bypasses the normal "Git aware" transport

47 mechanism and clones the repository by making a copy of

48 HEAD and everything under objects and refs directories.

49 The files under `.git/objects/` directory are hardlinked

@@ -54,11 +54,11 @@ this is the default, and --local is essentially a no-op. If the

54 repository is specified as a URL, then this flag is ignored (and we

55 never use the local optimizations). Specifying `--no-local` will

56 override the default when `/path/to/repo` is given, using the regular

57 -git transport instead.

57 +Git transport instead.

58 +

59 To force copying instead of hardlinking (which may be desirable if you

60 are trying to make a back-up of your repository), but still avoid the

61 -usual "git aware" transport mechanism, `--no-hardlinks` can be used.

61 +usual "Git aware" transport mechanism, `--no-hardlinks` can be used.

63 --no-hardlinks::

64 Optimize the cloning process from a repository on a

@@ -76,9 +76,9 @@ usual "git aware" transport mechanism, `--no-hardlinks` can be used.

76 *NOTE*: this is a possibly dangerous operation; do *not* use

77 it unless you understand what it does. If you clone your

78 repository using this option and then delete branches (or use any

79 -other git command that makes any existing commit unreferenced) in the

79 +other Git command that makes any existing commit unreferenced) in the

80 source repository, some objects may become unreferenced (or dangling).

81 -These objects may be removed by normal git operations (such as `git commit`)

81 +These objects may be removed by normal Git operations (such as `git commit`)

82 which automatically call `git gc --auto`. (See linkgit:git-gc[1].)

83 If these objects are removed and were referenced by the cloned repository,

84 then the cloned repository will become corrupt.

@@ -213,8 +213,8 @@ objects from the source repository into a pack in the cloned repository.

213 --separate-git-dir=<git dir>::

214 Instead of placing the cloned repository where it is supposed

215 to be, place the cloned repository at the specified directory,

216 - then make a filesytem-agnostic git symbolic link to there.

217 - The result is git repository can be separated from working

216 + then make a filesytem-agnostic Git symbolic link to there.

217 + The result is Git repository can be separated from working

218 tree.

219

220

Documentation/git-commit-tree.txt

+1 -1

@@ -30,7 +30,7 @@ While a tree represents a particular directory state of a working

30 directory, a commit represents that state in "time", and explains how

31 to get there.

33 -Normally a commit would identify a new "HEAD" state, and while git

33 +Normally a commit would identify a new "HEAD" state, and while Git

34 doesn't care where you save the note about that state, in practice we

35 tend to just write the result to the file that is pointed at by

36 `.git/HEAD`, so that we can always see what the last committed

Documentation/git-commit.txt

+3 -3

@@ -32,7 +32,7 @@ The content to be added can be specified in several ways:

32 3. by listing files as arguments to the 'commit' command, in which

33 case the commit will ignore changes staged in the index, and instead

34 record the current content of the listed files (which must already

35 - be known to git);

35 + be known to Git);

37 4. by using the -a switch with the 'commit' command to automatically

38 "add" changes from all known files (i.e. all files that are already

@@ -59,7 +59,7 @@ OPTIONS

59 --all::

60 Tell the command to automatically stage files that have

61 been modified and deleted, but new files you have not

62 - told git about are not affected.

62 + told Git about are not affected.

64 -p::

65 --patch::

@@ -404,7 +404,7 @@ Though not required, it's a good idea to begin the commit message

404 with a single short (less than 50 character) line summarizing the

405 change, followed by a blank line and then a more thorough description.

406 The text up to the first blank line in a commit message is treated

407 -as the commit title, and that title is used throughout git.

407 +as the commit title, and that title is used throughout Git.

408 For example, linkgit:git-format-patch[1] turns a commit into email, and it uses

409 the title on the Subject line and the rest of the commit in the body.

410

Documentation/git-credential-cache.txt

+2 -2

@@ -14,13 +14,13 @@ git config credential.helper 'cache [options]'

14 DESCRIPTION

15 -----------

17 -This command caches credentials in memory for use by future git

17 +This command caches credentials in memory for use by future Git

18 programs. The stored credentials never touch the disk, and are forgotten

19 after a configurable timeout. The cache is accessible over a Unix

20 domain socket, restricted to the current user by filesystem permissions.

22 You probably don't want to invoke this command directly; it is meant to

23 -be used as a credential helper by other parts of git. See

23 +be used as a credential helper by other parts of Git. See

24 linkgit:gitcredentials[7] or `EXAMPLES` below.

26 OPTIONS

Documentation/git-credential-store.txt

+3 -3

@@ -20,7 +20,7 @@ security tradeoff, try linkgit:git-credential-cache[1], or find a helper

20 that integrates with secure storage provided by your operating system.

22 This command stores credentials indefinitely on disk for use by future

23 -git programs.

23 +Git programs.

25 You probably don't want to invoke this command directly; it is meant to

26 be used as a credential helper by other parts of git. See

@@ -63,11 +63,11 @@ stored on its own line as a URL like:

63 https://user:pass@example.com

64 ------------------------------

66 -When git needs authentication for a particular URL context,

66 +When Git needs authentication for a particular URL context,

67 credential-store will consider that context a pattern to match against

68 each entry in the credentials file. If the protocol, hostname, and

69 username (if we already have one) match, then the password is returned

70 -to git. See the discussion of configuration in linkgit:gitcredentials[7]

70 +to Git. See the discussion of configuration in linkgit:gitcredentials[7]

71 for more information.

73 GIT

Documentation/git-credential.txt

+3 -3

@@ -18,9 +18,9 @@ Git has an internal interface for storing and retrieving credentials

18 from system-specific helpers, as well as prompting the user for

19 usernames and passwords. The git-credential command exposes this

20 interface to scripts which may want to retrieve, store, or prompt for

21 -credentials in the same manner as git. The design of this scriptable

21 +credentials in the same manner as Git. The design of this scriptable

22 interface models the internal C API; see

23 -link:technical/api-credentials.txt[the git credential API] for more

23 +link:technical/api-credentials.txt[the Git credential API] for more

24 background on the concepts.

26 git-credential takes an "action" option on the command-line (one of

@@ -74,7 +74,7 @@ infomation it has):

74 password=secr3t

75 +

76 In most cases, this means the attributes given in the input will be

77 -repeated in the output, but git may also modify the credential

77 +repeated in the output, but Git may also modify the credential

78 description, for example by removing the `path` attribute when the

79 protocol is HTTP(s) and `credential.useHttpPath` is false.

80 +

Documentation/git-cvsexportcommit.txt

+2 -2

@@ -16,7 +16,7 @@ SYNOPSIS

16 DESCRIPTION

17 -----------

18 Exports a commit from Git to a CVS checkout, making it easier

19 -to merge patches from a git repository into a CVS repository.

19 +to merge patches from a Git repository into a CVS repository.

21 Specify the name of a CVS checkout using the -w switch or execute it

22 from the root of the CVS working copy. In the latter case GIT_DIR must

@@ -71,7 +71,7 @@ OPTIONS

71 -w::

72 Specify the location of the CVS checkout to use for the export. This

73 option does not require GIT_DIR to be set before execution if the

74 - current directory is within a git repository. The default is the

74 + current directory is within a Git repository. The default is the

75 value of 'cvsexportcommit.cvsdir'.

77 -W::

Documentation/git-cvsimport.txt

+5 -5

@@ -18,7 +18,7 @@ SYNOPSIS

19 DESCRIPTION

20 -----------

21 -Imports a CVS repository into git. It will either create a new

21 +Imports a CVS repository into Git. It will either create a new

22 repository, or incrementally import into an existing one.

24 Splitting the CVS log into patch sets is done by 'cvsps'.

@@ -59,18 +59,18 @@ OPTIONS

59 `CVS/Repository`.

61 -C <target-dir>::

62 - The git repository to import to. If the directory doesn't

62 + The Git repository to import to. If the directory doesn't

63 exist, it will be created. Default is the current directory.

65 -r <remote>::

66 - The git remote to import this CVS repository into.

66 + The Git remote to import this CVS repository into.

67 Moves all CVS branches into remotes/<remote>/<branch>

68 akin to the way 'git clone' uses 'origin' by default.

70 -o <branch-for-HEAD>::

71 When no remote is specified (via -r) the 'HEAD' branch

72 - from CVS is imported to the 'origin' branch within the git

73 - repository, as 'HEAD' already has a special meaning for git.

72 + from CVS is imported to the 'origin' branch within the Git

73 + repository, as 'HEAD' already has a special meaning for Git.

74 When a remote is specified the 'HEAD' branch is named

75 remotes/<remote>/master mirroring 'git clone' behaviour.

76 Use this option if you want to import into a different

Documentation/git-cvsserver.txt

+10 -10

@@ -3,7 +3,7 @@ git-cvsserver(1)

4 NAME

5 ----

6 -git-cvsserver - A CVS server emulator for git

6 +git-cvsserver - A CVS server emulator for Git

8 SYNOPSIS

9 --------

@@ -60,7 +60,7 @@ unless '--export-all' was given, too.

60 DESCRIPTION

61 -----------

63 -This application is a CVS emulation layer for git.

63 +This application is a CVS emulation layer for Git.

65 It is highly functional. However, not all methods are implemented,

66 and for those methods that are implemented,

@@ -160,9 +160,9 @@ with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean

160 Note: you need to ensure each user that is going to invoke 'git-cvsserver' has

161 write access to the log file and to the database (see

162 <<dbbackend,Database Backend>>. If you want to offer write access over

163 -SSH, the users of course also need write access to the git repository itself.

163 +SSH, the users of course also need write access to the Git repository itself.

164

165 -You also need to ensure that each repository is "bare" (without a git index

165 +You also need to ensure that each repository is "bare" (without a Git index

166 file) for `cvs commit` to work. See linkgit:gitcvs-migration[7].

167

168 [[configaccessmethod]]

@@ -181,7 +181,7 @@ allowing access over SSH.

181 3. If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command,

182 automatically saving it in your 'CVS/Root' files, then you need to set them

183 explicitly in your environment. CVSROOT should be set as per normal, but the

184 - directory should point at the appropriate git repo. As above, for SSH clients

184 + directory should point at the appropriate Git repo. As above, for SSH clients

185 _not_ restricted to 'git-shell', CVS_SERVER should be set to 'git-cvsserver'.

186 +

187 --

@@ -210,7 +210,7 @@ allowing access over SSH.

210 Database Backend

211 ----------------

212

213 -'git-cvsserver' uses one database per git head (i.e. CVS module) to

213 +'git-cvsserver' uses one database per Git head (i.e. CVS module) to

214 store information about the repository to maintain consistent

215 CVS revision numbers. The database needs to be

216 updated (i.e. written to) after every commit.

@@ -225,7 +225,7 @@ the pserver method), 'git-cvsserver' should have write access to

225 the database to work reliably (otherwise you need to make sure

226 that the database is up-to-date any time 'git-cvsserver' is executed).

227

228 -By default it uses SQLite databases in the git directory, named

228 +By default it uses SQLite databases in the Git directory, named

229 `gitcvs.<module_name>.sqlite`. Note that the SQLite backend creates

230 temporary files in the same directory as the database file on

231 write so it might not be enough to grant the users using

@@ -291,14 +291,14 @@ Variable substitution

291 In `dbdriver` and `dbuser` you can use the following variables:

292

293 %G::

294 - git directory name

294 + Git directory name

295 %g::

296 - git directory name, where all characters except for

296 + Git directory name, where all characters except for

297 alpha-numeric ones, `.`, and `-` are replaced with

298 `_` (this should make it easier to use the directory

299 name in a filename if wanted)

300 %m::

301 - CVS module/git head name

301 + CVS module/Git head name

302 %a::

303 access method (one of "ext" or "pserver")

304 %u::

Documentation/git-daemon.txt

+4 -4

@@ -3,7 +3,7 @@ git-daemon(1)

4 NAME

5 ----

6 -git-daemon - A really simple server for git repositories

6 +git-daemon - A really simple server for Git repositories

8 SYNOPSIS

9 --------

@@ -22,12 +22,12 @@ SYNOPSIS

23 DESCRIPTION

24 -----------

25 -A really simple TCP git daemon that normally listens on port "DEFAULT_GIT_PORT"

25 +A really simple TCP Git daemon that normally listens on port "DEFAULT_GIT_PORT"

26 aka 9418. It waits for a connection asking for a service, and will serve

27 that service if it is enabled.

29 It verifies that the directory has the magic file "git-daemon-export-ok", and

30 -it will refuse to export any git directory that hasn't explicitly been marked

30 +it will refuse to export any Git directory that hasn't explicitly been marked

31 for export this way (unless the '--export-all' parameter is specified). If you

32 pass some directory paths as 'git daemon' arguments, you can further restrict

33 the offers to a whitelist comprising of those.

@@ -37,7 +37,7 @@ By default, only `upload-pack` service is enabled, which serves

37 from 'git fetch', 'git pull', and 'git clone'.

39 This is ideally suited for read-only updates, i.e., pulling from

40 -git repositories.

40 +Git repositories.

42 An `upload-archive` also exists to serve 'git archive'.

Documentation/git-describe.txt

+1 -1

@@ -131,7 +131,7 @@ closest tagname without any suffix:

131

132 Note that the suffix you get if you type these commands today may be

133 longer than what Linus saw above when he ran these commands, as your

134 -git repository may have new commits whose object names begin with

134 +Git repository may have new commits whose object names begin with

135 975b that did not exist back then, and "-g975b" suffix alone may not

136 be sufficient to disambiguate these commits.

137

Documentation/git-diff.txt

+1 -1

@@ -25,7 +25,7 @@ between two files on disk.

26 This form is to view the changes you made relative to

27 the index (staging area for the next commit). In other

28 - words, the differences are what you _could_ tell git to

28 + words, the differences are what you _could_ tell Git to

29 further add to the index but you still haven't. You can

30 stage these changes by using linkgit:git-add[1].

31 +

Documentation/git-difftool.txt

+1 -1

@@ -12,7 +12,7 @@ SYNOPSIS

13 DESCRIPTION

14 -----------

15 -'git difftool' is a git command that allows you to compare and edit files

15 +'git difftool' is a Git command that allows you to compare and edit files

16 between revisions using common diff tools. 'git difftool' is a frontend

17 to 'git diff' and accepts the same options and arguments. See

18 linkgit:git-diff[1].

Documentation/git-fetch.txt

+1 -1

@@ -80,7 +80,7 @@ Using --recurse-submodules can only fetch new commits in already checked

80 out submodules right now. When e.g. upstream added a new submodule in the

81 just fetched commits of the superproject the submodule itself can not be

82 fetched, making it impossible to check out that submodule later without

83 -having to do a fetch again. This is expected to be fixed in a future git

83 +having to do a fetch again. This is expected to be fixed in a future Git

84 version.

86 SEE ALSO

Documentation/git-filter-branch.txt

+3 -3

@@ -18,7 +18,7 @@ SYNOPSIS

19 DESCRIPTION

20 -----------

21 -Lets you rewrite git revision history by rewriting the branches mentioned

21 +Lets you rewrite Git revision history by rewriting the branches mentioned

22 in the <rev-list options>, applying custom filters on each revision.

23 Those filters can modify each tree (e.g. removing a file or running

24 a perl rewrite on all files) or information about each commit.

@@ -29,7 +29,7 @@ The command will only rewrite the _positive_ refs mentioned in the

29 command line (e.g. if you pass 'a..b', only 'b' will be rewritten).

30 If you specify no filters, the commits will be recommitted without any

31 changes, which would normally have no effect. Nevertheless, this may be

32 -useful in the future for compensating for some git bugs or such,

32 +useful in the future for compensating for some Git bugs or such,

33 therefore such a usage is permitted.

35 *NOTE*: This command honors `.git/info/grafts` file and refs in

@@ -374,7 +374,7 @@ git-filter-branch is often used to get rid of a subset of files,

374 usually with some combination of `--index-filter` and

375 `--subdirectory-filter`. People expect the resulting repository to

376 be smaller than the original, but you need a few more steps to

377 -actually make it smaller, because git tries hard not to lose your

377 +actually make it smaller, because Git tries hard not to lose your

378 objects until you tell it to. First make sure that:

379

380 * You really removed all variants of a filename, if a blob was moved

Documentation/git-format-patch.txt

+5 -5

@@ -208,14 +208,14 @@ The expected use case of this is to write supporting explanation for

208 the commit that does not belong to the commit log message proper,

209 and include it with the patch submission. While one can simply write

210 these explanations after `format-patch` has run but before sending,

211 -keeping them as git notes allows them to be maintained between versions

211 +keeping them as Git notes allows them to be maintained between versions

212 of the patch series (but see the discussion of the `notes.rewrite`

213 configuration options in linkgit:git-notes[1] to use this workflow).

214

215 --[no]-signature=<signature>::

216 Add a signature to each message produced. Per RFC 3676 the signature

217 is separated from the body by a line with '-- ' on it. If the

218 - signature option is omitted the signature defaults to the git version

218 + signature option is omitted the signature defaults to the Git version

219 number.

220

221 --suffix=.<sfx>::

@@ -389,7 +389,7 @@ Thunderbird

389 ~~~~~~~~~~~

390 By default, Thunderbird will both wrap emails as well as flag

391 them as being 'format=flowed', both of which will make the

392 -resulting email unusable by git.

392 +resulting email unusable by Git.

393

394 There are three different approaches: use an add-on to turn off line wraps,

395 configure Thunderbird to not mangle patches, or use

@@ -525,8 +525,8 @@ $ git format-patch -M -B origin

525 Additionally, it detects and handles renames and complete rewrites

526 intelligently to produce a renaming patch. A renaming patch reduces

527 the amount of text output, and generally makes it easier to review.

528 -Note that non-git "patch" programs won't understand renaming patches, so

529 -use it only when you know the recipient uses git to apply your patch.

528 +Note that non-Git "patch" programs won't understand renaming patches, so

529 +use it only when you know the recipient uses Git to apply your patch.

530

531 * Extract three topmost commits from the current branch and format them

532 as e-mailable patches:

Documentation/git-fsck.txt

+3 -3

@@ -56,7 +56,7 @@ index file, all SHA1 references in `refs` namespace, and all reflogs

56 ($GIT_DIR/objects), but also the ones found in alternate

57 object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES

58 or $GIT_DIR/objects/info/alternates,

59 - and in packed git archives found in $GIT_DIR/objects/pack

59 + and in packed Git archives found in $GIT_DIR/objects/pack

60 and corresponding pack subdirectories in alternate

61 object pools. This is now default; you can turn it off

62 with --no-full.

@@ -64,8 +64,8 @@ index file, all SHA1 references in `refs` namespace, and all reflogs

64 --strict::

65 Enable more strict checking, namely to catch a file mode

66 recorded with g+w bit set, which was created by older

67 - versions of git. Existing repositories, including the

68 - Linux kernel, git itself, and sparse repository have old

67 + versions of Git. Existing repositories, including the

68 + Linux kernel, Git itself, and sparse repository have old

69 objects that triggers this check, but it is recommended

70 to check new projects with this flag.

Documentation/git-grep.txt

+1 -1

@@ -61,7 +61,7 @@ OPTIONS

61 blobs registered in the index file.

63 --no-index::

64 - Search files in the current directory that is not managed by git.

64 + Search files in the current directory that is not managed by Git.

66 --untracked::

67 In addition to searching in the tracked files in the working

Documentation/git-gui.txt

+1 -1

@@ -102,7 +102,7 @@ Examples

102 SEE ALSO

103 --------

104 linkgit:gitk[1]::

105 - The git repository browser. Shows branches, commit history

105 + The Git repository browser. Shows branches, commit history

106 and file differences. gitk is the utility started by

107 'git gui''s Repository Visualize actions.

108

Documentation/git-hash-object.txt

+1 -1

@@ -40,7 +40,7 @@ OPTIONS

40 --path::

41 Hash object as it were located at the given path. The location of

42 file does not directly influence on the hash value, but path is

43 - used to determine what git filters should be applied to the object

43 + used to determine what Git filters should be applied to the object

44 before it can be placed to the object database, and, as result of

45 applying filters, the actual blob put into the object database may

46 differ from the given file. This option is mainly useful for hashing

Documentation/git-help.txt

+3 -3

@@ -3,7 +3,7 @@ git-help(1)

4 NAME

5 ----

6 -git-help - display help information about git

6 +git-help - Display help information about Git

8 SYNOPSIS

9 --------

@@ -14,13 +14,13 @@ DESCRIPTION

14 -----------

16 With no options and no COMMAND given, the synopsis of the 'git'

17 -command and a list of the most commonly used git commands are printed

17 +command and a list of the most commonly used Git commands are printed

18 on the standard output.

20 If the option '--all' or '-a' is given, then all available commands are

21 printed on the standard output.

23 -If a git command is named, a manual page for that command is brought

23 +If a Git subcommand is named, a manual page for that subcommand is brought

24 up. The 'man' program is used by default for this purpose, but this

25 can be overridden by other options or configuration variables.

Documentation/git-http-backend.txt

+1 -1

@@ -19,7 +19,7 @@ and the backwards-compatible dumb HTTP protocol, as well as clients

19 pushing using the smart HTTP protocol.

21 It verifies that the directory has the magic file

22 -"git-daemon-export-ok", and it will refuse to export any git directory

22 +"git-daemon-export-ok", and it will refuse to export any Git directory

23 that hasn't explicitly been marked for export this way (unless the

24 GIT_HTTP_EXPORT_ALL environmental variable is set).

Documentation/git-http-fetch.txt

+2 -2

@@ -3,7 +3,7 @@ git-http-fetch(1)

4 NAME

5 ----

6 -git-http-fetch - Download from a remote git repository via HTTP

6 +git-http-fetch - Download from a remote Git repository via HTTP

9 SYNOPSIS

@@ -13,7 +13,7 @@ SYNOPSIS

14 DESCRIPTION

15 -----------

16 -Downloads a remote git repository via HTTP.

16 +Downloads a remote Git repository via HTTP.

18 *NOTE*: use of this command without -a is deprecated. The -a

19 behaviour will become the default in a future release.

Documentation/git-index-pack.txt

+3 -3

@@ -19,7 +19,7 @@ DESCRIPTION

19 Reads a packed archive (.pack) from the specified file, and

20 builds a pack index file (.idx) for it. The packed archive

21 together with the pack index can then be placed in the

22 -objects/pack/ directory of a git repository.

22 +objects/pack/ directory of a Git repository.

25 OPTIONS

@@ -39,7 +39,7 @@ OPTIONS

39 When this flag is provided, the pack is read from stdin

40 instead and a copy is then written to <pack-file>. If

41 <pack-file> is not specified, the pack is written to

42 - objects/pack/ directory of the current git repository with

42 + objects/pack/ directory of the current Git repository with

43 a default name determined from the pack content. If

44 <pack-file> is not specified consider using --keep to

45 prevent a race condition between this process and

@@ -81,7 +81,7 @@ OPTIONS

81 This is meant to reduce packing time on multiprocessor

82 machines. The required amount of memory for the delta search

83 window is however multiplied by the number of threads.

84 - Specifying 0 will cause git to auto-detect the number of CPU's

84 + Specifying 0 will cause Git to auto-detect the number of CPU's

85 and use maximum 3 threads.

Documentation/git-init-db.txt

+1 -1

@@ -3,7 +3,7 @@ git-init-db(1)

4 NAME

5 ----

6 -git-init-db - Creates an empty git repository

6 +git-init-db - Creates an empty Git repository

9 SYNOPSIS

Documentation/git-init.txt

+8 -8

@@ -3,7 +3,7 @@ git-init(1)

4 NAME

5 ----

6 -git-init - Create an empty git repository or reinitialize an existing one

6 +git-init - Create an empty Git repository or reinitialize an existing one

9 SYNOPSIS

@@ -17,7 +17,7 @@ SYNOPSIS

17 DESCRIPTION

18 -----------

20 -This command creates an empty git repository - basically a `.git`

20 +This command creates an empty Git repository - basically a `.git`

21 directory with subdirectories for `objects`, `refs/heads`,

22 `refs/tags`, and template files. An initial `HEAD` file that

23 references the HEAD of the master branch is also created.

@@ -58,19 +58,19 @@ DIRECTORY" section below.)

58 --separate-git-dir=<git dir>::

60 Instead of initializing the repository where it is supposed to be,

61 -place a filesytem-agnostic git symbolic link there, pointing to the

62 -specified git path, and initialize a git repository at the path. The

63 -result is git repository can be separated from working tree. If this

61 +place a filesytem-agnostic Git symbolic link there, pointing to the

62 +specified path, and initialize a Git repository at the path. The

63 +result is Git repository can be separated from working tree. If this

64 is reinitialization, the repository will be moved to the specified

65 path.

69 -Specify that the git repository is to be shared amongst several users. This

69 +Specify that the Git repository is to be shared amongst several users. This

70 allows users belonging to the same group to push into that

71 repository. When specified, the config variable "core.sharedRepository" is

72 set so that files and directories under `$GIT_DIR` are created with the

73 -requested permissions. When not specified, git will use permissions reported

73 +requested permissions. When not specified, Git will use permissions reported

74 by umask(2).

76 The option can have the following values, defaulting to 'group' if no value

@@ -130,7 +130,7 @@ The suggested patterns and hook files are all modifiable and extensible.

130 EXAMPLES

131 --------

132

133 -Start a new git repository for an existing code base::

133 +Start a new Git repository for an existing code base::

134 +

135 ----------------

136 $ cd /path/to/my/codebase

Documentation/git-log.txt

+1 -1

@@ -64,7 +64,7 @@ produced by --stat etc.

65 --log-size::

66 Before the log message print out its size in bytes. Intended

67 - mainly for porcelain tools consumption. If git is unable to

67 + mainly for porcelain tools consumption. If Git is unable to

68 produce a valid value size is set to zero.

69 Note that only message is considered, if also a diff is shown

70 its size is not included.

Documentation/git-ls-files.txt

+1 -1

@@ -92,7 +92,7 @@ OPTIONS

92 directory and its subdirectories in <file>.

94 --exclude-standard::

95 - Add the standard git exclusions: .git/info/exclude, .gitignore

95 + Add the standard Git exclusions: .git/info/exclude, .gitignore

96 in each directory, and the user's global exclusion file.

98 --error-unmatch::

Documentation/git-merge-index.txt

+2 -2

@@ -41,13 +41,13 @@ If 'git merge-index' is called with multiple <file>s (or -a) then it

41 processes them in turn only stopping if merge returns a non-zero exit

42 code.

44 -Typically this is run with a script calling git's imitation of

44 +Typically this is run with a script calling Git's imitation of

45 the 'merge' command from the RCS package.

47 A sample script called 'git merge-one-file' is included in the

48 distribution.

50 -ALERT ALERT ALERT! The git "merge object order" is different from the

50 +ALERT ALERT ALERT! The Git "merge object order" is different from the

51 RCS 'merge' program merge object order. In the above ordering, the

52 original is first. But the argument order to the 3-way merge program

53 'merge' is to have the original in the middle. Don't ask me why.

Documentation/git-merge.txt

+2 -2

@@ -178,10 +178,10 @@ of the merge. Among the changes made to the common ancestor's version,

178 non-overlapping ones (that is, you changed an area of the file while the

179 other side left that area intact, or vice versa) are incorporated in the

180 final result verbatim. When both sides made changes to the same area,

181 -however, git cannot randomly pick one side over the other, and asks you to

181 +however, Git cannot randomly pick one side over the other, and asks you to

182 resolve it by leaving what both sides did to that area.

183

184 -By default, git uses the same style as the one used by the "merge" program

184 +By default, Git uses the same style as the one used by the "merge" program

185 from the RCS suite to present such a conflicted hunk, like this:

186

187 ------------

Documentation/git-mergetool--lib.txt

+2 -2

@@ -3,7 +3,7 @@ git-mergetool{litdd}lib(1)

4 NAME

5 ----

6 -git-mergetool--lib - Common git merge tool shell scriptlets

6 +git-mergetool--lib - Common Git merge tool shell scriptlets

8 SYNOPSIS

9 --------

@@ -19,7 +19,7 @@ Porcelain-ish scripts and/or are writing new ones.

20 The 'git-mergetool{litdd}lib' scriptlet is designed to be sourced (using

21 `.`) by other shell scripts to set up functions for working

22 -with git merge tools.

22 +with Git merge tools.

24 Before sourcing 'git-mergetool{litdd}lib', your script must set `TOOL_MODE`

25 to define the operation mode for the functions listed below.

Documentation/git-mktag.txt

+2 -2

@@ -28,9 +28,9 @@ A tag signature file has a very simple fixed format: four lines of

28 tagger <tagger>

30 followed by some 'optional' free-form message (some tags created

31 -by older git may not have `tagger` line). The message, when

31 +by older Git may not have `tagger` line). The message, when

32 exists, is separated by a blank line from the header. The

33 -message part may contain a signature that git itself doesn't

33 +message part may contain a signature that Git itself doesn't

34 care about, but that can be verified with gpg.

36 GIT

Documentation/git-p4.txt

+42 -42

@@ -18,13 +18,13 @@ SYNOPSIS

18 DESCRIPTION

19 -----------

20 This command provides a way to interact with p4 repositories

21 -using git.

21 +using Git.

23 -Create a new git repository from an existing p4 repository using

23 +Create a new Git repository from an existing p4 repository using

24 'git p4 clone', giving it one or more p4 depot paths. Incorporate

25 new commits from p4 changes with 'git p4 sync'. The 'sync' command

26 is also used to include new branches from other p4 depot paths.

27 -Submit git changes back to p4 using 'git p4 submit'. The command

27 +Submit Git changes back to p4 using 'git p4 submit'. The command

28 'git p4 rebase' does a sync plus rebases the current branch onto

29 the updated p4 remote branch.

@@ -37,7 +37,7 @@ EXAMPLE

37 $ git p4 clone //depot/path/project

38 ------------

40 -* Do some work in the newly created git repository:

40 +* Do some work in the newly created Git repository:

41 +

42 ------------

43 $ cd project

@@ -45,7 +45,7 @@ $ vi foo.h

45 $ git commit -a -m "edited foo.h"

46 ------------

48 -* Update the git repository with recent changes from p4, rebasing your

48 +* Update the Git repository with recent changes from p4, rebasing your

49 work on top:

50 +

51 ------------

@@ -64,21 +64,21 @@ COMMANDS

65 Clone

66 ~~~~~

67 -Generally, 'git p4 clone' is used to create a new git directory

67 +Generally, 'git p4 clone' is used to create a new Git directory

68 from an existing p4 repository:

69 ------------

70 $ git p4 clone //depot/path/project

71 ------------

72 This:

74 -1. Creates an empty git repository in a subdirectory called 'project'.

74 +1. Creates an empty Git repository in a subdirectory called 'project'.

75 +

76 2. Imports the full contents of the head revision from the given p4

77 -depot path into a single commit in the git branch 'refs/remotes/p4/master'.

77 +depot path into a single commit in the Git branch 'refs/remotes/p4/master'.

78 +

79 3. Creates a local branch, 'master' from this remote and checks it out.

81 -To reproduce the entire p4 history in git, use the '@all' modifier on

81 +To reproduce the entire p4 history in Git, use the '@all' modifier on

82 the depot path:

83 ------------

84 $ git p4 clone //depot/path/project@all

@@ -88,13 +88,13 @@ $ git p4 clone //depot/path/project@all

88 Sync

89 ~~~~

90 As development continues in the p4 repository, those changes can

91 -be included in the git repository using:

91 +be included in the Git repository using:

92 ------------

93 $ git p4 sync

94 ------------

95 -This command finds new changes in p4 and imports them as git commits.

95 +This command finds new changes in p4 and imports them as Git commits.

97 -P4 repositories can be added to an existing git repository using

97 +P4 repositories can be added to an existing Git repository using

98 'git p4 sync' too:

99 ------------

100 $ mkdir repo-git

@@ -103,14 +103,14 @@ $ git init

103 $ git p4 sync //path/in/your/perforce/depot

104 ------------

105 This imports the specified depot into

106 -'refs/remotes/p4/master' in an existing git repository. The

106 +'refs/remotes/p4/master' in an existing Git repository. The

107 '--branch' option can be used to specify a different branch to

108 be used for the p4 content.

109

110 -If a git repository includes branches 'refs/remotes/origin/p4', these

110 +If a Git repository includes branches 'refs/remotes/origin/p4', these

111 will be fetched and consulted first during a 'git p4 sync'. Since

112 importing directly from p4 is considerably slower than pulling changes

113 -from a git remote, this can be useful in a multi-developer environment.

113 +from a Git remote, this can be useful in a multi-developer environment.

114

115

116 Rebase

@@ -127,13 +127,13 @@ $ git p4 rebase

127

128 Submit

129 ~~~~~~

130 -Submitting changes from a git repository back to the p4 repository

130 +Submitting changes from a Git repository back to the p4 repository

131 requires a separate p4 client workspace. This should be specified

132 -using the 'P4CLIENT' environment variable or the git configuration

132 +using the 'P4CLIENT' environment variable or the Git configuration

133 variable 'git-p4.client'. The p4 client must exist, but the client root

134 will be created and populated if it does not already exist.

135

136 -To submit all changes that are in the current git branch but not in

136 +To submit all changes that are in the current Git branch but not in

137 the 'p4/master' branch, use:

138 ------------

139 $ git p4 submit

@@ -149,7 +149,7 @@ be overridden using the '--origin=' command-line option.

149

150 The p4 changes will be created as the user invoking 'git p4 submit'. The

151 '--preserve-user' option will cause ownership to be modified

152 -according to the author of the git commit. This option requires admin

152 +according to the author of the Git commit. This option requires admin

153 privileges in p4, which can be granted using 'p4 protect'.

154

155

@@ -178,7 +178,7 @@ subsequent 'sync' operations.

178 with an initial clone, no HEAD will be checked out.

179 +

180 This example imports a new remote "p4/proj2" into an existing

181 -git repository:

181 +Git repository:

182 +

183 ----

184 $ git init

@@ -199,11 +199,11 @@ git repository:

199

200 --detect-labels::

201 Query p4 for labels associated with the depot paths, and add

202 - them as tags in git. Limited usefulness as only imports labels

202 + them as tags in Git. Limited usefulness as only imports labels

203 associated with new changelists. Deprecated.

204

205 --import-labels::

206 - Import labels from p4 into git.

206 + Import labels from p4 into Git.

207

208 --import-local::

209 By default, p4 branches are stored in 'refs/remotes/p4/',

@@ -219,12 +219,12 @@ git repository:

219 specifier.

220

221 --keep-path::

222 - The mapping of file names from the p4 depot path to git, by

222 + The mapping of file names from the p4 depot path to Git, by

223 default, involves removing the entire depot path. With this

224 - option, the full p4 depot path is retained in git. For example,

224 + option, the full p4 depot path is retained in Git. For example,

225 path '//depot/main/foo/bar.c', when imported from

226 '//depot/main/', becomes 'foo/bar.c'. With '--keep-path', the

227 - git path is instead 'depot/main/foo/bar.c'.

227 + Git path is instead 'depot/main/foo/bar.c'.

228

229 --use-client-spec::

230 Use a client spec to find the list of interesting files in p4.

@@ -236,7 +236,7 @@ These options can be used in an initial 'clone', along with the 'sync'

236 options described above.

237

238 --destination <directory>::

239 - Where to create the git repository. If not provided, the last

239 + Where to create the Git repository. If not provided, the last

240 component in the p4 depot path is used to create a new

241 directory.

242

@@ -266,12 +266,12 @@ These options can be used to modify 'git p4 submit' behavior.

266 requires p4 admin privileges.

267

268 --export-labels::

269 - Export tags from git as p4 labels. Tags found in git are applied

269 + Export tags from Git as p4 labels. Tags found in Git are applied

270 to the perforce working directory.

271

272 --dry-run, -n::

273 Show just what commits would be submitted to p4; do not change

274 - state in git or p4.

274 + state in Git or p4.

275

276 --prepare-p4-only::

277 Apply a commit to the p4 workspace, opening, adding and deleting

@@ -312,12 +312,12 @@ p4 revision specifier on the end:

312 "//depot/proj1@all //depot/proj2@all"::

313 Import all changes from both named depot paths into a single

314 repository. Only files below these directories are included.

315 - There is not a subdirectory in git for each "proj1" and "proj2".

315 + There is not a subdirectory in Git for each "proj1" and "proj2".

316 You must use the '--destination' option when specifying more

317 than one depot path. The revision specifier must be specified

318 identically on each depot path. If there are files in the

319 depot paths with the same name, the path with the most recently

320 - updated version of the file is the one that appears in git.

320 + updated version of the file is the one that appears in Git.

321

322 See 'p4 help revisions' for the full syntax of p4 revision specifiers.

323

@@ -334,11 +334,11 @@ configuration file. This allows future 'git p4 submit' commands to

334 work properly; the submit command looks only at the variable and does

335 not have a command-line option.

336

337 -The full syntax for a p4 view is documented in 'p4 help views'. 'Git p4'

337 +The full syntax for a p4 view is documented in 'p4 help views'. 'git p4'

338 knows only a subset of the view syntax. It understands multi-line

339 mappings, overlays with '+', exclusions with '-' and double-quotes

340 around whitespace. Of the possible wildcards, 'git p4' only handles

341 -'...', and only when it is at the end of the path. 'Git p4' will complain

341 +'...', and only when it is at the end of the path. 'git p4' will complain

342 if it encounters an unhandled wildcard.

343

344 Bugs in the implementation of overlap mappings exist. If multiple depot

@@ -354,7 +354,7 @@ variable P4CLIENT, a file referenced by P4CONFIG, or the local host name.

354

355 BRANCH DETECTION

356 ----------------

357 -P4 does not have the same concept of a branch as git. Instead,

357 +P4 does not have the same concept of a branch as Git. Instead,

358 p4 organizes its content as a directory tree, where by convention

359 different logical branches are in different locations in the tree.

360 The 'p4 branch' command is used to maintain mappings between

@@ -364,7 +364,7 @@ can use these mappings to determine branch relationships.

364 If you have a repository where all the branches of interest exist as

365 subdirectories of a single depot path, you can use '--detect-branches'

366 when cloning or syncing to have 'git p4' automatically find

367 -subdirectories in p4, and to generate these as branches in git.

367 +subdirectories in p4, and to generate these as branches in Git.

368

369 For example, if the P4 repository structure is:

370 ----

@@ -386,7 +386,7 @@ called 'master', and one for //depot/branch1 called 'depot/branch1'.

386

387 However, it is not necessary to create branches in p4 to be able to use

388 them like branches. Because it is difficult to infer branch

389 -relationships automatically, a git configuration setting

389 +relationships automatically, a Git configuration setting

390 'git-p4.branchList' can be used to explicitly identify branch

391 relationships. It is a list of "source:destination" pairs, like a

392 simple p4 branch specification, where the "source" and "destination" are

@@ -402,7 +402,7 @@ git p4 clone --detect-branches //depot@all

402 PERFORMANCE

403 -----------

404 The fast-import mechanism used by 'git p4' creates one pack file for

405 -each invocation of 'git p4 sync'. Normally, git garbage compression

405 +each invocation of 'git p4 sync'. Normally, Git garbage compression

406 (linkgit:git-gc[1]) automatically compresses these to fewer pack files,

407 but explicit invocation of 'git repack -adf' may improve performance.

408

@@ -440,9 +440,9 @@ git-p4.client::

440 Clone and sync variables

441 ~~~~~~~~~~~~~~~~~~~~~~~~

442 git-p4.syncFromOrigin::

443 - Because importing commits from other git repositories is much faster

443 + Because importing commits from other Git repositories is much faster

444 than importing them from p4, a mechanism exists to find p4 changes

445 - first in git remotes. If branches exist under 'refs/remote/origin/p4',

445 + first in Git remotes. If branches exist under 'refs/remote/origin/p4',

446 those will be fetched and used when syncing from p4. This

447 variable can be set to 'false' to disable this behavior.

448

@@ -494,7 +494,7 @@ git-p4.detectCopiesHarder::

494 Detect copies harder. See linkgit:git-diff[1]. A boolean.

495

496 git-p4.preserveUser::

497 - On submit, re-author changes to reflect the git author,

497 + On submit, re-author changes to reflect the Git author,

498 regardless of who invokes 'git p4 submit'.

499

500 git-p4.allowMissingP4Users::

@@ -531,7 +531,7 @@ git-p4.attemptRCSCleanup::

531 present.

532

533 git-p4.exportLabels::

534 - Export git tags to p4 labels, as per --export-labels.

534 + Export Git tags to p4 labels, as per --export-labels.

535

536 git-p4.labelExportRegexp::

537 Only p4 labels matching this regular expression will be exported. The

@@ -543,11 +543,11 @@ git-p4.conflict::

543

544 IMPLEMENTATION DETAILS

545 ----------------------

546 -* Changesets from p4 are imported using git fast-import.

546 +* Changesets from p4 are imported using Git fast-import.

547 * Cloning or syncing does not require a p4 client; file contents are

548 collected using 'p4 print'.

549 * Submitting requires a p4 client, which is not in the same location

550 - as the git repository. Patches are applied, one at a time, to

550 + as the Git repository. Patches are applied, one at a time, to

551 this p4 client and submitted from there.

552 * Each commit imported by 'git p4' has a line at the end of the log

553 message indicating the p4 depot location and change number. This

Documentation/git-pack-objects.txt

+6 -6

@@ -35,7 +35,7 @@ A pack index file (.idx) is generated for fast, random access to the

35 objects in the pack. Placing both the index file (.idx) and the packed

36 archive (.pack) in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or

37 any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)

38 -enables git to read from the pack archive.

38 +enables Git to read from the pack archive.

40 The 'git unpack-objects' command can read the packed archive and

41 expand the objects contained in the pack into "one-file

@@ -80,7 +80,7 @@ base-name::

80 --include-tag::

81 Include unasked-for annotated tags if the object they

82 reference was included in the resulting packfile. This

83 - can be useful to send new tags to native git clients.

83 + can be useful to send new tags to native Git clients.

85 --window=<n>::

86 --depth=<n>::

@@ -185,14 +185,14 @@ base-name::

185 option only makes sense in conjunction with --stdout.

186 +

187 Note: A thin pack violates the packed archive format by omitting

188 -required objects and is thus unusable by git without making it

188 +required objects and is thus unusable by Git without making it

189 self-contained. Use `git index-pack --fix-thin`

190 (see linkgit:git-index-pack[1]) to restore the self-contained property.

191

192 --delta-base-offset::

193 A packed archive can express the base object of a delta as

194 either a 20-byte object name or as an offset in the

195 - stream, but ancient versions of git don't understand the

195 + stream, but ancient versions of Git don't understand the

196 latter. By default, 'git pack-objects' only uses the

197 former format for better compatibility. This option

198 allows the command to use the latter format for

@@ -202,7 +202,7 @@ self-contained. Use `git index-pack --fix-thin`

202 +

203 Note: Porcelain commands such as `git gc` (see linkgit:git-gc[1]),

204 `git repack` (see linkgit:git-repack[1]) pass this option by default

205 -in modern git when they put objects in your repository into pack files.

205 +in modern Git when they put objects in your repository into pack files.

206 So does `git bundle` (see linkgit:git-bundle[1]) when it creates a bundle.

207

208 --threads=<n>::

@@ -212,7 +212,7 @@ So does `git bundle` (see linkgit:git-bundle[1]) when it creates a bundle.

212 This is meant to reduce packing time on multiprocessor machines.

213 The required amount of memory for the delta search window is

214 however multiplied by the number of threads.

215 - Specifying 0 will cause git to auto-detect the number of CPU's

215 + Specifying 0 will cause Git to auto-detect the number of CPU's

216 and set the number of threads accordingly.

217

218 --index-version=<version>[,<offset>]::

Documentation/git-pull.txt

+4 -4

@@ -59,8 +59,8 @@ and a log message from the user describing the changes.

59 See linkgit:git-merge[1] for details, including how conflicts

60 are presented and handled.

62 -In git 1.7.0 or later, to cancel a conflicting merge, use

63 -`git reset --merge`. *Warning*: In older versions of git, running 'git pull'

62 +In Git 1.7.0 or later, to cancel a conflicting merge, use

63 +`git reset --merge`. *Warning*: In older versions of Git, running 'git pull'

64 with uncommitted changes is discouraged: while possible, it leaves you

65 in a state that may be hard to back out of in the case of a conflict.

@@ -89,7 +89,7 @@ must be given before the options meant for 'git fetch'.

89 This option controls if new commits of all populated submodules should

90 be fetched too (see linkgit:git-config[1] and linkgit:gitmodules[5]).

91 That might be necessary to get the data needed for merging submodule

92 - commits, a feature git learned in 1.7.3. Notice that the result of a

92 + commits, a feature Git learned in 1.7.3. Notice that the result of a

93 merge will not be checked out in the submodule, "git submodule update"

94 has to be called afterwards to bring the work tree up to date with the

95 merge result.

@@ -228,7 +228,7 @@ Using --recurse-submodules can only fetch new commits in already checked

228 out submodules right now. When e.g. upstream added a new submodule in the

229 just fetched commits of the superproject the submodule itself can not be

230 fetched, making it impossible to check out that submodule later without

231 -having to do a fetch again. This is expected to be fixed in a future git

231 +having to do a fetch again. This is expected to be fixed in a future Git

232 version.

233

234 SEE ALSO

Documentation/git-push.txt

+4 -4

@@ -53,7 +53,7 @@ updated.

53 The object referenced by <src> is used to update the <dst> reference

54 on the remote side. By default this is only allowed if <dst> is not

55 a tag (annotated or lightweight), and then only if it can fast-forward

56 -<dst>. By having the optional leading `+`, you can tell git to update

56 +<dst>. By having the optional leading `+`, you can tell Git to update

57 the <dst> ref even if it is not allowed by default (e.g., it is not a

58 fast-forward.) This does *not* attempt to merge <src> into <dst>. See

59 EXAMPLES below for details.

@@ -64,7 +64,7 @@ Pushing an empty <src> allows you to delete the <dst> ref from

64 the remote repository.

65 +

66 The special refspec `:` (or `+:` to allow non-fast-forward updates)

67 -directs git to push "matching" branches: for every branch that exists on

67 +directs Git to push "matching" branches: for every branch that exists on

68 the local side, the remote side is updated if a branch of the same name

69 already exists on the remote side. This is the default operation mode

70 if no explicit refspec is found (that is neither on the command line

@@ -177,7 +177,7 @@ useful if you write an alias or script around 'git push'.

177 --recurse-submodules=check|on-demand::

178 Make sure all submodule commits used by the revisions to be

179 pushed are available on a remote-tracking branch. If 'check' is

180 - used git will verify that all submodule commits that changed in

180 + used Git will verify that all submodule commits that changed in

181 the revisions to be pushed are available on at least one remote

182 of the submodule. If any commits are missing the push will be

183 aborted and exit with non-zero status. If 'on-demand' is used

@@ -192,7 +192,7 @@ OUTPUT

192 ------

193

194 The output of "git push" depends on the transport method used; this

195 -section describes the output when pushing over the git protocol (either

195 +section describes the output when pushing over the Git protocol (either

196 locally or via ssh).

197

198 The status of the push is output in tabular form, with each line

Documentation/git-quiltimport.txt

+2 -2

@@ -14,7 +14,7 @@ SYNOPSIS

15 DESCRIPTION

16 -----------

17 -Applies a quilt patchset onto the current git branch, preserving

17 +Applies a quilt patchset onto the current Git branch, preserving

18 the patch boundaries, patch order, and patch descriptions present

19 in the quilt patchset.

@@ -25,7 +25,7 @@ the patch description is displayed and the user is asked to

25 interactively enter the author of the patch.

27 If a subject is not found in the patch description the patch name is

28 -preserved as the 1 line subject in the git description.

28 +preserved as the 1 line subject in the Git description.

30 OPTIONS

31 -------

Documentation/git-rebase.txt

+1 -1

@@ -179,7 +179,7 @@ parameter can be any valid commit-ish.

179 In case of conflict, 'git rebase' will stop at the first problematic commit

180 and leave conflict markers in the tree. You can use 'git diff' to locate

181 the markers (<<<<<<) and make edits to resolve the conflict. For each

182 -file you edit, you need to tell git that the conflict has been resolved,

182 +file you edit, you need to tell Git that the conflict has been resolved,

183 typically this would be done with

184

185

Documentation/git-reflog.txt

+1 -1

@@ -38,7 +38,7 @@ The reflog will cover all recent actions (HEAD reflog records branch switching

38 as well). It is an alias for `git log -g --abbrev-commit --pretty=oneline`;

39 see linkgit:git-log[1].

41 -The reflog is useful in various git commands, to specify the old value

41 +The reflog is useful in various Git commands, to specify the old value

42 of a reference. For example, `HEAD@{2}` means "where HEAD used to be

43 two moves ago", `master@{one.week.ago}` means "where master used to

44 point to one week ago", and so on. See linkgit:gitrevisions[7] for

Documentation/git-remote-ext.txt

+7 -7

@@ -13,7 +13,7 @@ git remote add <nick> "ext::<command>[ <arguments>...]"

13 DESCRIPTION

14 -----------

15 This remote helper uses the specified '<command>' to connect

16 -to a remote git server.

16 +to a remote Git server.

18 Data written to stdin of the specified '<command>' is assumed

19 to be sent to a git:// server, git-upload-pack, git-receive-pack

@@ -33,12 +33,12 @@ The following sequences have a special meaning:

34 '%s'::

35 Replaced with name (receive-pack, upload-pack, or

36 - upload-archive) of the service git wants to invoke.

36 + upload-archive) of the service Git wants to invoke.

38 '%S'::

39 Replaced with long name (git-receive-pack,

40 git-upload-pack, or git-upload-archive) of the service

41 - git wants to invoke.

41 + Git wants to invoke.

43 '%G' (must be the first characters in an argument)::

44 This argument will not be passed to '<command>'. Instead, it

@@ -75,7 +75,7 @@ GIT_EXT_SERVICE_NOPREFIX::

76 EXAMPLES:

77 ---------

78 -This remote helper is transparently used by git when

78 +This remote helper is transparently used by Git when

79 you use commands such as "git fetch <URL>", "git clone <URL>",

80 , "git push <URL>" or "git remote add <nick> <URL>", where <URL>

81 begins with `ext::`. Examples:

@@ -100,14 +100,14 @@ begins with `ext::`. Examples:

100 Represents a repository with path /repo accessed using the

101 helper program "git-server-alias foo". The hostname for the

102 remote server passed in the protocol stream will be "foo"

103 - (this allows multiple virtual git servers to share a

103 + (this allows multiple virtual Git servers to share a

104 link-level address).

105

106 "ext::git-server-alias foo %G/repo% with% spaces %Vfoo"::

107 Represents a repository with path '/repo with spaces' accessed

108 using the helper program "git-server-alias foo". The hostname for

109 the remote server passed in the protocol stream will be "foo"

110 - (this allows multiple virtual git servers to share a

110 + (this allows multiple virtual Git servers to share a

111 link-level address).

112

113 "ext::git-ssl foo.example /bar"::

@@ -118,7 +118,7 @@ begins with `ext::`. Examples:

118

119 Documentation

120 --------------

121 -Documentation by Ilari Liusvaara, Jonathan Nieder and the git list

121 +Documentation by Ilari Liusvaara, Jonathan Nieder and the Git list

122 <git@vger.kernel.org>

123

124 GIT

Documentation/git-remote-fd.txt

+4 -4

@@ -11,14 +11,14 @@ SYNOPSIS

12 DESCRIPTION

13 -----------

14 -This helper uses specified file descriptors to connect to a remote git server.

14 +This helper uses specified file descriptors to connect to a remote Git server.

15 This is not meant for end users but for programs and scripts calling git

16 fetch, push or archive.

18 If only <infd> is given, it is assumed to be a bidirectional socket connected

19 -to remote git server (git-upload-pack, git-receive-pack or

19 +to remote Git server (git-upload-pack, git-receive-pack or

20 git-upload-achive). If both <infd> and <outfd> are given, they are assumed

21 -to be pipes connected to a remote git server (<infd> being the inbound pipe

21 +to be pipes connected to a remote Git server (<infd> being the inbound pipe

22 and <outfd> being the outbound pipe.

24 It is assumed that any handshaking procedures have already been completed

@@ -52,7 +52,7 @@ EXAMPLES

53 Documentation

54 --------------

55 -Documentation by Ilari Liusvaara and the git list <git@vger.kernel.org>

55 +Documentation by Ilari Liusvaara and the Git list <git@vger.kernel.org>

57 GIT

58 ---

Documentation/git-remote-helpers.txt

+24 -24

@@ -14,17 +14,17 @@ DESCRIPTION

14 -----------

16 Remote helper programs are normally not used directly by end users,

17 -but they are invoked by git when it needs to interact with remote

18 -repositories git does not support natively. A given helper will

19 -implement a subset of the capabilities documented here. When git

17 +but they are invoked by Git when it needs to interact with remote

18 +repositories Git does not support natively. A given helper will

19 +implement a subset of the capabilities documented here. When Git

20 needs to interact with a repository using a remote helper, it spawns

21 the helper as an independent process, sends commands to the helper's

22 standard input, and expects results from the helper's standard

23 output. Because a remote helper runs as an independent process from

24 -git, there is no need to re-link git to add a new helper, nor any

25 -need to link the helper with the implementation of git.

24 +Git, there is no need to re-link Git to add a new helper, nor any

25 +need to link the helper with the implementation of Git.

27 -Every helper must support the "capabilities" command, which git

27 +Every helper must support the "capabilities" command, which Git

28 uses to determine what other commands the helper will accept. Those

29 other commands can be used to discover and update remote refs,

30 transport objects between the object database and the remote repository,

@@ -39,15 +39,15 @@ INVOCATION

39 ----------

41 Remote helper programs are invoked with one or (optionally) two

42 -arguments. The first argument specifies a remote repository as in git;

42 +arguments. The first argument specifies a remote repository as in Git;

43 it is either the name of a configured remote or a URL. The second

44 argument specifies a URL; it is usually of the form

45 '<transport>://<address>', but any arbitrary string is possible.

46 The 'GIT_DIR' environment variable is set up for the remote helper

47 and can be used to determine where to store additional data or from

48 -which directory to invoke auxiliary git commands.

48 +which directory to invoke auxiliary Git commands.

50 -When git encounters a URL of the form '<transport>://<address>', where

50 +When Git encounters a URL of the form '<transport>://<address>', where

51 '<transport>' is a protocol that it cannot handle natively, it

52 automatically invokes 'git remote-<transport>' with the full URL as

53 the second argument. If such a URL is encountered directly on the

@@ -55,14 +55,14 @@ command line, the first argument is the same as the second, and if it

55 is encountered in a configured remote, the first argument is the name

56 of that remote.

58 -A URL of the form '<transport>::<address>' explicitly instructs git to

58 +A URL of the form '<transport>::<address>' explicitly instructs Git to

59 invoke 'git remote-<transport>' with '<address>' as the second

60 argument. If such a URL is encountered directly on the command line,

61 the first argument is '<address>', and if it is encountered in a

62 configured remote, the first argument is the name of that remote.

64 Additionally, when a configured remote has 'remote.<name>.vcs' set to

65 -'<transport>', git explicitly invokes 'git remote-<transport>' with

65 +'<transport>', Git explicitly invokes 'git remote-<transport>' with

66 '<name>' as the first argument. If set, the second argument is

67 'remote.<name>.url'; otherwise, the second argument is omitted.

@@ -85,7 +85,7 @@ Capabilities

85 ~~~~~~~~~~~~

87 Each remote helper is expected to support only a subset of commands.

88 -The operations a helper supports are declared to git in the response

88 +The operations a helper supports are declared to Git in the response

89 to the `capabilities` command (see COMMANDS, below).

91 In the following, we list all defined capabilities and for

@@ -114,10 +114,10 @@ Supported commands: 'list for-push', 'push'.

114 +

115 Supported commands: 'list for-push', 'export'.

116

117 -If a helper advertises 'connect', git will use it if possible and

117 +If a helper advertises 'connect', Git will use it if possible and

118 fall back to another capability if the helper requests so when

119 connecting (see the 'connect' command under COMMANDS).

120 -When choosing between 'push' and 'export', git prefers 'push'.

120 +When choosing between 'push' and 'export', Git prefers 'push'.

121 Other frontends may have some other order of preference.

122

123

@@ -126,7 +126,7 @@ Capabilities for Fetching

126 'connect'::

127 Can try to connect to 'git upload-pack' (for fetching),

128 'git receive-pack', etc for communication using the

129 - git's native packfile protocol. This

129 + Git's native packfile protocol. This

130 requires a bidirectional, full-duplex connection.

131 +

132 Supported commands: 'connect'.

@@ -143,10 +143,10 @@ Supported commands: 'list', 'fetch'.

143 +

144 Supported commands: 'list', 'import'.

145

146 -If a helper advertises 'connect', git will use it if possible and

146 +If a helper advertises 'connect', Git will use it if possible and

147 fall back to another capability if the helper requests so when

148 connecting (see the 'connect' command under COMMANDS).

149 -When choosing between 'fetch' and 'import', git prefers 'fetch'.

149 +When choosing between 'fetch' and 'import', Git prefers 'fetch'.

150 Other frontends may have some other order of preference.

151

152 Miscellaneous capabilities

@@ -183,22 +183,22 @@ there is an implied `refspec *:*`.

183 to retrieve information about blobs and trees that already exist in

184 fast-import's memory. This requires a channel from fast-import to the

185 remote-helper.

186 - If it is advertised in addition to "import", git establishes a pipe from

186 + If it is advertised in addition to "import", Git establishes a pipe from

187 fast-import to the remote-helper's stdin.

188 - It follows that git and fast-import are both connected to the

189 - remote-helper's stdin. Because git can send multiple commands to

188 + It follows that Git and fast-import are both connected to the

189 + remote-helper's stdin. Because Git can send multiple commands to

190 the remote-helper it is required that helpers that use 'bidi-import'

191 buffer all 'import' commands of a batch before sending data to fast-import.

192 This is to prevent mixing commands and fast-import responses on the

193 helper's stdin.

194

195 'export-marks' <file>::

196 - This modifies the 'export' capability, instructing git to dump the

196 + This modifies the 'export' capability, instructing Git to dump the

197 internal marks table to <file> when complete. For details,

198 read up on '--export-marks=<file>' in linkgit:git-fast-export[1].

199

200 'import-marks' <file>::

201 - This modifies the 'export' capability, instructing git to load the

201 + This modifies the 'export' capability, instructing Git to load the

202 marks specified in <file> before processing any input. For details,

203 read up on '--import-marks=<file>' in linkgit:git-fast-export[1].

204

@@ -213,7 +213,7 @@ Commands are given by the caller on the helper's standard input, one per line.

213 'capabilities'::

214 Lists the capabilities of the helper, one per line, ending

215 with a blank line. Each capability may be preceded with '*',

216 - which marks them mandatory for git versions using the remote

216 + which marks them mandatory for Git versions using the remote

217 helper to understand. Any unknown mandatory capability is a

218 fatal error.

219 +

@@ -376,7 +376,7 @@ OPTIONS

376 -------

377

378 The following options are defined and (under suitable circumstances)

379 -set by git if the remote helper has the 'option' capability.

379 +set by Git if the remote helper has the 'option' capability.

380

381 'option verbosity' <n>::

382 Changes the verbosity of messages displayed by the helper.

Documentation/git-replace.txt

+1 -1

@@ -22,7 +22,7 @@ replacement object.

23 Unless `-f` is given, the 'replace' reference must not yet exist.

25 -Replacement references will be used by default by all git commands

25 +Replacement references will be used by default by all Git commands

26 except those doing reachability traversal (prune, pack transfer and

27 fsck).

Documentation/git-rev-list.txt

+1 -1

@@ -99,7 +99,7 @@ between the two operands. The following two commands are equivalent:

99 $ git rev-list A...B

100 -----------------------------------------------------------------------

101

102 -'rev-list' is a very essential git command, since it

102 +'rev-list' is a very essential Git command, since it

103 provides the ability to build and traverse commit ancestry graphs. For

104 this reason, it has a lot of different options that enables it to be

105 used by commands as different as 'git bisect' and

Documentation/git-rev-parse.txt

+2 -2

@@ -14,7 +14,7 @@ SYNOPSIS

14 DESCRIPTION

15 -----------

17 -Many git porcelainish commands take mixture of flags

17 +Many Git porcelainish commands take mixture of flags

18 (i.e. parameters that begin with a dash '-') and parameters

19 meant for the underlying 'git rev-list' command they use internally

20 and flags and parameters for the other commands they use

@@ -147,7 +147,7 @@ shown. If the pattern does not contain a globbing character (`?`,

147 relative to the current working directory.

148 +

149 If `$GIT_DIR` is not defined and the current directory

150 -is not detected to lie in a git repository or work tree

150 +is not detected to lie in a Git repository or work tree

151 print a message to stderr and exit with nonzero status.

152

153 --is-inside-git-dir::

Documentation/git-rm.txt

+5 -5

@@ -28,7 +28,7 @@ OPTIONS

28 -------

29 <file>...::

30 Files to remove. Fileglobs (e.g. `*.c`) can be given to

31 - remove all matching files. If you want git to expand

31 + remove all matching files. If you want Git to expand

32 file glob characters, you may need to shell-escape them.

33 A leading directory name

34 (e.g. `dir` to remove `dir/file1` and `dir/file2`) can be

@@ -74,8 +74,8 @@ DISCUSSION

75 The <file> list given to the command can be exact pathnames,

76 file glob patterns, or leading directory names. The command

77 -removes only the paths that are known to git. Giving the name of

78 -a file that you have not told git about does not remove that file.

77 +removes only the paths that are known to Git. Giving the name of

78 +a file that you have not told Git about does not remove that file.

80 File globbing matches across directory boundaries. Thus, given

81 two directories `d` and `d2`, there is a difference between

@@ -137,7 +137,7 @@ git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached

137 Submodules

138 ~~~~~~~~~~

139 Only submodules using a gitfile (which means they were cloned

140 -with a git version 1.7.8 or newer) will be removed from the work

140 +with a Git version 1.7.8 or newer) will be removed from the work

141 tree, as their repository lives inside the .git directory of the

142 superproject. If a submodule (or one of those nested inside it)

143 still uses a .git directory, `git rm` will fail - no matter if forced

@@ -156,7 +156,7 @@ EXAMPLES

156 `Documentation` directory and any of its subdirectories.

157 +

158 Note that the asterisk `*` is quoted from the shell in this

159 -example; this lets git, and not the shell, expand the pathnames

159 +example; this lets Git, and not the shell, expand the pathnames

160 of files and subdirectories under the `Documentation/` directory.

161

162 `git rm -f git-*.sh`::

Documentation/git-send-pack.txt

+1 -1

@@ -3,7 +3,7 @@ git-send-pack(1)

4 NAME

5 ----

6 -git-send-pack - Push objects over git protocol to another repository

6 +git-send-pack - Push objects over Git protocol to another repository

9 SYNOPSIS

Documentation/git-sh-setup.txt

+2 -2

@@ -3,7 +3,7 @@ git-sh-setup(1)

4 NAME

5 ----

6 -git-sh-setup - Common git shell script setup code

6 +git-sh-setup - Common Git shell script setup code

8 SYNOPSIS

9 --------

@@ -19,7 +19,7 @@ Porcelain-ish scripts and/or are writing new ones.

20 The 'git sh-setup' scriptlet is designed to be sourced (using

21 `.`) by other shell scripts to set up some variables pointing at

22 -the normal git directories and a few helper shell functions.

22 +the normal Git directories and a few helper shell functions.

24 Before sourcing it, your script should set up a few variables;

25 `USAGE` (and `LONG_USAGE`, if any) is used to define message

Documentation/git-show-index.txt

+1 -1

@@ -14,7 +14,7 @@ SYNOPSIS

15 DESCRIPTION

16 -----------

17 -Reads given idx file for packed git archive created with

17 +Reads given idx file for packed Git archive created with

18 'git pack-objects' command, and dumps its contents.

20 The information it outputs is subset of what you can get from

Documentation/git-status.txt

+4 -4

@@ -16,7 +16,7 @@ DESCRIPTION

16 Displays paths that have differences between the index file and the

17 current HEAD commit, paths that have differences between the working

18 tree and the index file, and paths in the working tree that are not

19 -tracked by git (and are not ignored by linkgit:gitignore[5]). The first

19 +tracked by Git (and are not ignored by linkgit:gitignore[5]). The first

20 are what you _would_ commit by running `git commit`; the second and

21 third are what you _could_ commit by running 'git add' before running

22 `git commit`.

@@ -35,7 +35,7 @@ OPTIONS

35 --porcelain::

36 Give the output in an easy-to-parse format for scripts.

37 This is similar to the short output, but will remain stable

38 - across git versions and regardless of user configuration. See

38 + across Git versions and regardless of user configuration. See

39 below for details.

41 --long::

@@ -96,7 +96,7 @@ The default, long format, is designed to be human readable,

96 verbose and descriptive. Its contents and format are subject to change

97 at any time.

99 -The paths mentioned in the output, unlike many other git commands, are

99 +The paths mentioned in the output, unlike many other Git commands, are

100 made relative to the current directory if you are working in a

101 subdirectory (this is on purpose, to help cutting and pasting). See

102 the status.relativePaths config option below.

@@ -168,7 +168,7 @@ Porcelain Format

168 ~~~~~~~~~~~~~~~~

169

170 The porcelain format is similar to the short format, but is guaranteed

171 -not to change in a backwards-incompatible way between git versions or

171 +not to change in a backwards-incompatible way between Git versions or

172 based on user configuration. This makes it ideal for parsing by scripts.

173 The description of the short format above also describes the porcelain

174 format, with a few exceptions:

Documentation/git-stripspace.txt

+1 -1

@@ -14,7 +14,7 @@ SYNOPSIS

14 DESCRIPTION

15 -----------

17 -Clean the input in the manner used by 'git' for text such as commit

17 +Clean the input in the manner used by Git for text such as commit

18 messages, notes, tags and branch descriptions.

20 With no arguments, this will:

Documentation/git-submodule.txt

+1 -1

@@ -91,7 +91,7 @@ working directory is used instead.

91 <path> is the relative location for the cloned submodule to

92 exist in the superproject. If <path> does not exist, then the

93 submodule is created by cloning from the named URL. If <path> does

94 -exist and is already a valid git repository, then this is added

94 +exist and is already a valid Git repository, then this is added

95 to the changeset without cloning. This second form is provided

96 to ease creating a new submodule from scratch, and presumes

97 the user will later push the submodule to the given URL.

Documentation/git-svn.txt

+44 -44

@@ -3,7 +3,7 @@ git-svn(1)

4 NAME

5 ----

6 -git-svn - Bidirectional operation between a Subversion repository and git

6 +git-svn - Bidirectional operation between a Subversion repository and Git

8 SYNOPSIS

9 --------

@@ -12,8 +12,8 @@ SYNOPSIS

13 DESCRIPTION

14 -----------

15 -'git svn' is a simple conduit for changesets between Subversion and git.

16 -It provides a bidirectional flow of changes between a Subversion and a git

15 +'git svn' is a simple conduit for changesets between Subversion and Git.

16 +It provides a bidirectional flow of changes between a Subversion and a Git

17 repository.

19 'git svn' can track a standard Subversion repository,

@@ -21,15 +21,15 @@ following the common "trunk/branches/tags" layout, with the --stdlayout option.

21 It can also follow branches and tags in any layout with the -T/-t/-b options

22 (see options to 'init' below, and also the 'clone' command).

24 -Once tracking a Subversion repository (with any of the above methods), the git

24 +Once tracking a Subversion repository (with any of the above methods), the Git

25 repository can be updated from Subversion by the 'fetch' command and

26 -Subversion updated from git by the 'dcommit' command.

26 +Subversion updated from Git by the 'dcommit' command.

28 COMMANDS

29 --------

31 'init'::

32 - Initializes an empty git repository with additional

32 + Initializes an empty Git repository with additional

33 metadata directories for 'git svn'. The Subversion URL

34 may be specified as a command-line argument, or as full

35 URL arguments to -T/-t/-b. Optionally, the target

@@ -199,9 +199,9 @@ and have no uncommitted changes.

199 Commit each diff from the current branch directly to the SVN

200 repository, and then rebase or reset (depending on whether or

201 not there is a diff between SVN and head). This will create

202 - a revision in SVN for each commit in git.

202 + a revision in SVN for each commit in Git.

203 +

204 -When an optional git branch name (or a git commit object name)

204 +When an optional Git branch name (or a Git commit object name)

205 is specified as an argument, the subcommand works on the specified

206 branch, not on the current branch.

207 +

@@ -316,7 +316,7 @@ New features:

316 +

317 --

318 --show-commit;;

319 - shows the git commit sha1, as well

319 + shows the Git commit sha1, as well

320 --oneline;;

321 our version of --pretty=oneline

322 --

@@ -337,13 +337,13 @@ Any other arguments are passed directly to 'git log'

337 +

338 --git-format;;

339 Produce output in the same format as 'git blame', but with

340 - SVN revision numbers instead of git commit hashes. In this mode,

340 + SVN revision numbers instead of Git commit hashes. In this mode,

341 changes that haven't been committed to SVN (including local

342 working-copy edits) are shown as revision 0.

343

344 'find-rev'::

345 When given an SVN revision number of the form 'rN', returns the

346 - corresponding git commit hash (this can optionally be followed by a

346 + corresponding Git commit hash (this can optionally be followed by a

347 tree-ish to specify which branch should be searched). When given a

348 tree-ish, returns the corresponding SVN revision number.

349 +

@@ -378,7 +378,7 @@ Any other arguments are passed directly to 'git log'

378 the $GIT_DIR/info/exclude file.

379

380 'mkdirs'::

381 - Attempts to recreate empty directories that core git cannot track

381 + Attempts to recreate empty directories that core Git cannot track

382 based on information in $GIT_DIR/svn/<refname>/unhandled.log files.

383 Empty directories are automatically recreated when using

384 "git svn clone" and "git svn rebase", so "mkdirs" is intended

@@ -510,9 +510,9 @@ order. Only the leading sha1 is read from each line, so

510 +

511 Remove directories from the SVN tree if there are no files left

512 behind. SVN can version empty directories, and they are not

513 -removed by default if there are no files left in them. git

513 +removed by default if there are no files left in them. Git

514 cannot version empty directories. Enabling this flag will make

515 -the commit to SVN act like git.

515 +the commit to SVN act like Git.

516 +

517 [verse]

518 config key: svn.rmdir

@@ -599,7 +599,7 @@ Passed directly to 'git rebase' when using 'dcommit' if a

599 This can be used with the 'dcommit', 'rebase', 'branch' and

600 'tag' commands.

601 +

602 -For 'dcommit', print out the series of git arguments that would show

602 +For 'dcommit', print out the series of Git arguments that would show

603 which diffs would be committed to SVN.

604 +

605 For 'rebase', display the local branch associated with the upstream svn

@@ -610,14 +610,14 @@ For 'branch' and 'tag', display the urls that will be used for copying when

610 creating the branch or tag.

611

612 --use-log-author::

613 - When retrieving svn commits into git (as part of 'fetch', 'rebase', or

613 + When retrieving svn commits into Git (as part of 'fetch', 'rebase', or

614 'dcommit' operations), look for the first `From:` or `Signed-off-by:` line

615 in the log message and use that as the author string.

616 --add-author-from::

617 - When committing to svn from git (as part of 'commit-diff', 'set-tree' or 'dcommit'

617 + When committing to svn from Git (as part of 'commit-diff', 'set-tree' or 'dcommit'

618 operations), if the existing log message doesn't already have a

619 `From:` or `Signed-off-by:` line, append a `From:` line based on the

620 - git commit's author string. If you use this, then `--use-log-author`

620 + Git commit's author string. If you use this, then `--use-log-author`

621 will retrieve a valid author string for all commits.

622

623

@@ -642,7 +642,7 @@ ADVANCED OPTIONS

642 one of the repository layout options --trunk, --tags,

643 --branches, --stdlayout). For each tracked branch, try to find

644 out where its revision was copied from, and set

645 - a suitable parent in the first git commit for the branch.

645 + a suitable parent in the first Git commit for the branch.

646 This is especially helpful when we're tracking a directory

647 that has been moved around within the repository. If this

648 feature is disabled, the branches created by 'git svn' will all

@@ -674,7 +674,7 @@ option for (hopefully) obvious reasons.

674 +

675 This option is NOT recommended as it makes it difficult to track down

676 old references to SVN revision numbers in existing documentation, bug

677 -reports and archives. If you plan to eventually migrate from SVN to git

677 +reports and archives. If you plan to eventually migrate from SVN to Git

678 and are certain about dropping SVN history, consider

679 linkgit:git-filter-branch[1] instead. filter-branch also allows

680 reformatting of metadata for ease-of-reading and rewriting authorship

@@ -714,7 +714,7 @@ svn-remote.<name>.rewriteUUID::

714

715 svn-remote.<name>.pushurl::

716

717 - Similar to git's 'remote.<name>.pushurl', this key is designed

717 + Similar to Git's 'remote.<name>.pushurl', this key is designed

718 to be used in cases where 'url' points to an SVN repository

719 via a read-only transport, to provide an alternate read/write

720 transport. It is assumed that both keys point to the same

@@ -768,15 +768,15 @@ Tracking and contributing to the trunk of a Subversion-managed project

768 cd trunk

769 # You should be on master branch, double-check with 'git branch'

770 git branch

771 -# Do some work and commit locally to git:

771 +# Do some work and commit locally to Git:

772 git commit ...

773 # Something is committed to SVN, rebase your local changes against the

774 # latest changes in SVN:

775 git svn rebase

776 -# Now commit your changes (that were committed previously using git) to SVN,

776 +# Now commit your changes (that were committed previously using Git) to SVN,

777 # as well as automatically updating your working HEAD:

778 git svn dcommit

779 -# Append svn:ignore settings to the default git exclude file:

779 +# Append svn:ignore settings to the default Git exclude file:

780 git svn show-ignore >> .git/info/exclude

781 ------------------------------------------------------------------------

782

@@ -816,7 +816,7 @@ have each person clone that repository with 'git clone':

816 git remote add origin server:/pub/project

817 git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'

818 git fetch

819 -# Prevent fetch/pull from remote git server in the future,

819 +# Prevent fetch/pull from remote Git server in the future,

820 # we only want to use git svn for future updates

821 git config --remove-section remote.origin

822 # Create a local branch from one of the branches just fetched

@@ -849,13 +849,13 @@ While 'git svn' can track

849 copy history (including branches and tags) for repositories adopting a

850 standard layout, it cannot yet represent merge history that happened

851 inside git back upstream to SVN users. Therefore it is advised that

852 -users keep history as linear as possible inside git to ease

852 +users keep history as linear as possible inside Git to ease

853 compatibility with SVN (see the CAVEATS section below).

854

855 HANDLING OF SVN BRANCHES

856 ------------------------

857 If 'git svn' is configured to fetch branches (and --follow-branches

858 -is in effect), it sometimes creates multiple git branches for one

858 +is in effect), it sometimes creates multiple Git branches for one

859 SVN branch, where the addtional branches have names of the form

860 'branchname@nnn' (with nnn an SVN revision number). These additional

861 branches are created if 'git svn' cannot find a parent commit for the

@@ -865,17 +865,17 @@ the other branches.

865 Normally, the first commit in an SVN branch consists

866 of a copy operation. 'git svn' will read this commit to get the SVN

867 revision the branch was created from. It will then try to find the

868 -git commit that corresponds to this SVN revision, and use that as the

868 +Git commit that corresponds to this SVN revision, and use that as the

869 parent of the branch. However, it is possible that there is no suitable

870 -git commit to serve as parent. This will happen, among other reasons,

870 +Git commit to serve as parent. This will happen, among other reasons,

871 if the SVN branch is a copy of a revision that was not fetched by 'git

872 svn' (e.g. because it is an old revision that was skipped with

873 '--revision'), or if in SVN a directory was copied that is not tracked

874 by 'git svn' (such as a branch that is not tracked at all, or a

875 subdirectory of a tracked branch). In these cases, 'git svn' will still

876 -create a git branch, but instead of using an existing git commit as the

876 +create a Git branch, but instead of using an existing Git commit as the

877 parent of the branch, it will read the SVN history of the directory the

878 -branch was copied from and create appropriate git commits. This is

878 +branch was copied from and create appropriate Git commits. This is

879 indicated by the message "Initializing parent: <branchname>".

880

881 Additionally, it will create a special branch named

@@ -885,15 +885,15 @@ created parent commit of the branch. If in SVN the branch was deleted

885 and later recreated from a different version, there will be multiple

886 such branches with an '@'.

887

888 -Note that this may mean that multiple git commits are created for a

888 +Note that this may mean that multiple Git commits are created for a

889 single SVN revision.

890

891 An example: in an SVN repository with a standard

892 trunk/tags/branches layout, a directory trunk/sub is created in r.100.

893 In r.200, trunk/sub is branched by copying it to branches/. 'git svn

894 -clone -s' will then create a branch 'sub'. It will also create new git

894 +clone -s' will then create a branch 'sub'. It will also create new Git

895 commits for r.100 through r.199 and use these as the history of branch

896 -'sub'. Thus there will be two git commits for each revision from r.100

896 +'sub'. Thus there will be two Git commits for each revision from r.100

897 to r.199 (one containing trunk/, one containing trunk/sub/). Finally,

898 it will create a branch 'sub@200' pointing to the new parent commit of

899 branch 'sub' (i.e. the commit for r.200 and trunk/sub/).

@@ -904,13 +904,13 @@ CAVEATS

904 For the sake of simplicity and interoperating with Subversion,

905 it is recommended that all 'git svn' users clone, fetch and dcommit

906 directly from the SVN server, and avoid all 'git clone'/'pull'/'merge'/'push'

907 -operations between git repositories and branches. The recommended

908 -method of exchanging code between git branches and users is

907 +operations between Git repositories and branches. The recommended

908 +method of exchanging code between Git branches and users is

909 'git format-patch' and 'git am', or just 'dcommit'ing to the SVN repository.

910

911 Running 'git merge' or 'git pull' is NOT recommended on a branch you

912 plan to 'dcommit' from because Subversion users cannot see any

913 -merges you've made. Furthermore, if you merge or pull from a git branch

913 +merges you've made. Furthermore, if you merge or pull from a Git branch

914 that is a mirror of an SVN branch, 'dcommit' may commit to the wrong

915 branch.

916

@@ -929,7 +929,7 @@ any 'git svn' metadata, or config. So repositories created and managed with

929 using 'git svn' should use 'rsync' for cloning, if cloning is to be done

930 at all.

931

932 -Since 'dcommit' uses rebase internally, any git branches you 'git push' to

932 +Since 'dcommit' uses rebase internally, any Git branches you 'git push' to

933 before 'dcommit' on will require forcing an overwrite of the existing ref

934 on the remote repository. This is generally considered bad practice,

935 see the linkgit:git-push[1] documentation for details.

@@ -941,7 +941,7 @@ dcommit with SVN is analogous to that.

941

942 When cloning an SVN repository, if none of the options for describing

943 the repository layout is used (--trunk, --tags, --branches,

944 ---stdlayout), 'git svn clone' will create a git repository with

944 +--stdlayout), 'git svn clone' will create a Git repository with

945 completely linear history, where branches and tags appear as separate

946 directories in the working copy. While this is the easiest way to get a

947 copy of a complete repository, for projects with many branches it will

@@ -957,7 +957,7 @@ branches and tags is required, the options '--trunk' / '--branches' /

957 When using multiple --branches or --tags, 'git svn' does not automatically

958 handle name collisions (for example, if two branches from different paths have

959 the same name, or if a branch and a tag have the same name). In these cases,

960 -use 'init' to set up your git repository then, before your first 'fetch', edit

960 +use 'init' to set up your Git repository then, before your first 'fetch', edit

961 the .git/config file so that the branches and tags are associated with

962 different name spaces. For example:

963

@@ -970,12 +970,12 @@ BUGS

970 We ignore all SVN properties except svn:executable. Any unhandled

971 properties are logged to $GIT_DIR/svn/<refname>/unhandled.log

972

973 -Renamed and copied directories are not detected by git and hence not

973 +Renamed and copied directories are not detected by Git and hence not

974 tracked when committing to SVN. I do not plan on adding support for

975 this as it's quite difficult and time-consuming to get working for all

976 -the possible corner cases (git doesn't do it, either). Committing

976 +the possible corner cases (Git doesn't do it, either). Committing

977 renamed and copied files is fully supported if they're similar enough

978 -for git to detect them.

978 +for Git to detect them.

979

980 In SVN, it is possible (though discouraged) to commit changes to a tag

981 (because a tag is just a directory copy, thus technically the same as a

@@ -987,7 +987,7 @@ CONFIGURATION

987 -------------

988

989 'git svn' stores [svn-remote] configuration information in the

990 -repository .git/config file. It is similar the core git

990 +repository .git/config file. It is similar the core Git

991 [remote] sections except 'fetch' keys do not accept glob

992 arguments; but they are instead handled by the 'branches'

993 and 'tags' keys. Since some SVN repositories are oddly

Documentation/git-tag.txt

+1 -1

@@ -242,7 +242,7 @@ $ git pull git://git..../proj.git master

242 In such a case, you do not want to automatically follow the other

243 person's tags.

244

245 -One important aspect of git is its distributed nature, which

245 +One important aspect of Git is its distributed nature, which

246 largely means there is no inherent "upstream" or

247 "downstream" in the system. On the face of it, the above

248 example might seem to indicate that the tag namespace is owned

Documentation/git-tools.txt

+13 -13

@@ -1,11 +1,11 @@

1 -A short git tools survey

1 +A short Git tools survey

2 ========================

5 Introduction

6 ------------

8 -Apart from git contrib/ area there are some others third-party tools

8 +Apart from Git contrib/ area there are some others third-party tools

9 you may want to look.

11 This document presents a brief summary of each tool and the corresponding

@@ -17,7 +17,7 @@ Alternative/Augmentative Porcelains

18 - *Cogito* (http://www.kernel.org/pub/software/scm/cogito/)

20 - Cogito is a version control system layered on top of the git tree history

20 + Cogito is a version control system layered on top of the Git tree history

21 storage system. It aims at seamless user interface and ease of use,

22 providing generally smoother user experience than the "raw" Core Git

23 itself and indeed many other version control systems.

@@ -50,7 +50,7 @@ History Viewers

51 - *gitview* (contrib/)

53 - gitview is a GTK based repository browser for git

53 + gitview is a GTK based repository browser for Git

56 - *gitweb* (shipped with git-core)

@@ -63,15 +63,15 @@ History Viewers

63 QGit is a git/StGIT GUI viewer built on Qt/C++. QGit could be used

64 to browse history and directory tree, view annotated files, commit

65 changes cherry picking single files or applying patches.

66 - Currently it is the fastest and most feature rich among the git

66 + Currently it is the fastest and most feature rich among the Git

67 viewers and commit tools.

69 - *tig* (http://jonas.nitro.dk/tig/)

71 - tig by Jonas Fonseca is a simple git repository browser

71 + tig by Jonas Fonseca is a simple Git repository browser

72 written using ncurses. Basically, it just acts as a front-end

73 for git-log and git-show/git-diff. Additionally, you can also

74 - use it as a pager for git commands.

74 + use it as a pager for Git commands.

77 Foreign SCM interface

@@ -80,20 +80,20 @@ Foreign SCM interface

80 - *git-svn* (shipped with git-core)

82 git-svn is a simple conduit for changesets between a single Subversion

83 - branch and git.

83 + branch and Git.

86 - *quilt2git / git2quilt* (http://home-tj.org/wiki/index.php/Misc)

88 These utilities convert patch series in a quilt repository and commit

89 - series in git back and forth.

89 + series in Git back and forth.

92 - *hg-to-git* (contrib/)

94 - hg-to-git converts a Mercurial repository into a git one, and

94 + hg-to-git converts a Mercurial repository into a Git one, and

95 preserves the full branch history in the process. hg-to-git can

96 - also be used in an incremental way to keep the git repository

96 + also be used in an incremental way to keep the Git repository

97 in sync with the master Mercurial repository.

@@ -102,14 +102,14 @@ Others

102

103 - *(h)gct* (http://www.cyd.liu.se/users/~freku045/gct/)

104

105 - Commit Tool or (h)gct is a GUI enabled commit tool for git and

105 + Commit Tool or (h)gct is a GUI enabled commit tool for Git and

106 Mercurial (hg). It allows the user to view diffs, select which files

107 to committed (or ignored / reverted) write commit messages and

108 perform the commit itself.

109

110 - *git.el* (contrib/)

111

112 - This is an Emacs interface for git. The user interface is modeled on

112 + This is an Emacs interface for Git. The user interface is modeled on

113 pcl-cvs. It has been developed on Emacs 21 and will probably need some

114 tweaking to work on XEmacs.

115

Documentation/git-update-index.txt

+8 -8

@@ -82,10 +82,10 @@ OPTIONS

82 When these flags are specified, the object names recorded

83 for the paths are not updated. Instead, these options

84 set and unset the "assume unchanged" bit for the

85 - paths. When the "assume unchanged" bit is on, git stops

85 + paths. When the "assume unchanged" bit is on, Git stops

86 checking the working tree files for possible

87 modifications, so you need to manually unset the bit to

88 - tell git when you change the working tree file. This is

88 + tell Git when you change the working tree file. This is

89 sometimes helpful when working with a big project on a

90 filesystem that has very slow lstat(2) system call

91 (e.g. cifs).

@@ -253,18 +253,18 @@ $ git ls-files -s

253 Using ``assume unchanged'' bit

254 ------------------------------

255

256 -Many operations in git depend on your filesystem to have an

256 +Many operations in Git depend on your filesystem to have an

257 efficient `lstat(2)` implementation, so that `st_mtime`

258 information for working tree files can be cheaply checked to see

259 if the file contents have changed from the version recorded in

260 the index file. Unfortunately, some filesystems have

261 inefficient `lstat(2)`. If your filesystem is one of them, you

262 can set "assume unchanged" bit to paths you have not changed to

263 -cause git not to do this check. Note that setting this bit on a

264 -path does not mean git will check the contents of the file to

265 -see if it has changed -- it makes git to omit any checking and

263 +cause Git not to do this check. Note that setting this bit on a

264 +path does not mean Git will check the contents of the file to

265 +see if it has changed -- it makes Git to omit any checking and

266 assume it has *not* changed. When you make changes to working

267 -tree files, you have to explicitly tell git about it by dropping

267 +tree files, you have to explicitly tell Git about it by dropping

268 "assume unchanged" bit, either before or after you modify them.

269

270 In order to set "assume unchanged" bit, use `--assume-unchanged`

@@ -274,7 +274,7 @@ have the "assume unchanged" bit set, use `git ls-files -v`

274

275 The command looks at `core.ignorestat` configuration variable. When

276 this is true, paths updated with `git update-index paths...` and

277 -paths updated with other git commands that update both index and

277 +paths updated with other Git commands that update both index and

278 working tree (e.g. 'git apply --index', 'git checkout-index -u',

279 and 'git read-tree -u') are automatically marked as "assume

280 unchanged". Note that "assume unchanged" bit is *not* set if

Documentation/git-upload-archive.txt

+1 -1

@@ -14,7 +14,7 @@ SYNOPSIS

14 DESCRIPTION

15 -----------

16 Invoked by 'git archive --remote' and sends a generated archive to the

17 -other end over the git protocol.

17 +other end over the Git protocol.

19 This command is usually not invoked directly by the end user. The UI

20 for the protocol is on the 'git archive' side, and the program pair

Documentation/git-upload-pack.txt

+1 -1

@@ -26,7 +26,7 @@ OPTIONS

26 -------

28 --strict::

29 - Do not try <directory>/.git/ if <directory> is no git directory.

29 + Do not try <directory>/.git/ if <directory> is no Git directory.

31 --timeout=<n>::

32 Interrupt transfer after <n> seconds of inactivity.

Documentation/git-var.txt

+6 -6

@@ -3,7 +3,7 @@ git-var(1)

4 NAME

5 ----

6 -git-var - Show a git logical variable

6 +git-var - Show a Git logical variable

9 SYNOPSIS

@@ -13,13 +13,13 @@ SYNOPSIS

14 DESCRIPTION

15 -----------

16 -Prints a git logical variable.

16 +Prints a Git logical variable.

18 OPTIONS

19 -------

20 -l::

21 Cause the logical variables to be listed. In addition, all the

22 - variables of the git configuration file .git/config are listed

22 + variables of the Git configuration file .git/config are listed

23 as well. (However, the configuration variables listing functionality

24 is deprecated in favor of `git config -l`.)

@@ -35,10 +35,10 @@ GIT_AUTHOR_IDENT::

35 The author of a piece of code.

37 GIT_COMMITTER_IDENT::

38 - The person who put a piece of code into git.

38 + The person who put a piece of code into Git.

40 GIT_EDITOR::

41 - Text editor for use by git commands. The value is meant to be

41 + Text editor for use by Git commands. The value is meant to be

42 interpreted by the shell when it is used. Examples: `~/bin/vi`,

43 `$SOME_ENVIRONMENT_VARIABLE`, `"C:\Program Files\Vim\gvim.exe"

44 --nofork`. The order of preference is the `$GIT_EDITOR`

@@ -50,7 +50,7 @@ ifdef::git-default-editor[]

50 endif::git-default-editor[]

52 GIT_PAGER::

53 - Text viewer for use by git commands (e.g., 'less'). The value

53 + Text viewer for use by Git commands (e.g., 'less'). The value

54 is meant to be interpreted by the shell. The order of preference

55 is the `$GIT_PAGER` environment variable, then `core.pager`

56 configuration, then `$PAGER`, and then the default chosen at

Documentation/git-verify-pack.txt

+2 -2

@@ -3,7 +3,7 @@ git-verify-pack(1)

4 NAME

5 ----

6 -git-verify-pack - Validate packed git archive files

6 +git-verify-pack - Validate packed Git archive files

9 SYNOPSIS

@@ -14,7 +14,7 @@ SYNOPSIS

15 DESCRIPTION

16 -----------

17 -Reads given idx file for packed git archive created with the

17 +Reads given idx file for packed Git archive created with the

18 'git pack-objects' command and verifies idx file and the

19 corresponding pack file.

Documentation/git-verify-tag.txt

+1 -1

@@ -21,7 +21,7 @@ OPTIONS

21 Print the contents of the tag object before validating it.

23 <tag>...::

24 - SHA1 identifiers of git tag objects.

24 + SHA1 identifiers of Git tag objects.

26 GIT

27 ---

Documentation/git-web--browse.txt

+2 -2

@@ -3,7 +3,7 @@ git-web{litdd}browse(1)

4 NAME

5 ----

6 -git-web--browse - git helper script to launch a web browser

6 +git-web--browse - Git helper script to launch a web browser

8 SYNOPSIS

9 --------

@@ -50,7 +50,7 @@ OPTIONS

51 -c <conf.var>::

52 --config=<conf.var>::

53 - CONF.VAR is looked up in the git config files. If it's set,

53 + CONF.VAR is looked up in the Git config files. If it's set,

54 then its value specifies the browser that should be used.

56 CONFIGURATION VARIABLES

Documentation/git-whatchanged.txt

+2 -2

@@ -24,7 +24,7 @@ This manual page describes only the most frequently used options.

24 OPTIONS

25 -------

26 -p::

27 - Show textual diffs, instead of the git internal diff

27 + Show textual diffs, instead of the Git internal diff

28 output format that is useful only to tell the changed

29 paths and their nature of changes.

@@ -36,7 +36,7 @@ OPTIONS

36 exclusive, top inclusive).

38 -r::

39 - Show git internal diff output, but for the whole tree,

39 + Show Git internal diff output, but for the whole tree,

40 not just the top level.

42 -m::

Documentation/git.txt

+44 -44

@@ -27,11 +27,11 @@ commands. The link:user-manual.html[Git User's Manual] has a more

27 in-depth introduction.

29 After you mastered the basic concepts, you can come back to this

30 -page to learn what commands git offers. You can learn more about

31 -individual git commands with "git help command". linkgit:gitcli[7]

30 +page to learn what commands Git offers. You can learn more about

31 +individual Git commands with "git help command". linkgit:gitcli[7]

32 manual page gives you an overview of the command line command syntax.

34 -Formatted and hyperlinked version of the latest git documentation

34 +Formatted and hyperlinked version of the latest Git documentation

35 can be viewed at `http://git-htmldocs.googlecode.com/git/git.html`.

37 ifdef::stalenotes[]

@@ -39,7 +39,7 @@ ifdef::stalenotes[]

39 ============

41 You are reading the documentation for the latest (possibly

42 -unreleased) version of git, that is available from 'master'

42 +unreleased) version of Git, that is available from 'master'

43 branch of the `git.git` repository.

44 Documentation for older releases are available here:

@@ -355,12 +355,12 @@ endif::stalenotes[]

355 OPTIONS

356 -------

357 --version::

358 - Prints the git suite version that the 'git' program came from.

358 + Prints the Git suite version that the 'git' program came from.

359

360 --help::

361 Prints the synopsis and a list of the most commonly used

362 commands. If the option '--all' or '-a' is given then all

363 - available commands are printed. If a git command is named this

363 + available commands are printed. If a Git command is named this

364 option will bring up the manual page for that command.

365 +

366 Other options are available to control how the manual page is

@@ -375,22 +375,22 @@ help ...`.

375 'git config' (subkeys separated by dots).

376

377 --exec-path[=<path>]::

378 - Path to wherever your core git programs are installed.

378 + Path to wherever your core Git programs are installed.

379 This can also be controlled by setting the GIT_EXEC_PATH

380 environment variable. If no path is given, 'git' will print

381 the current setting and then exit.

382

383 --html-path::

384 - Print the path, without trailing slash, where git's HTML

384 + Print the path, without trailing slash, where Git's HTML

385 documentation is installed and exit.

386

387 --man-path::

388 Print the manpath (see `man(1)`) for the man pages for

389 - this version of git and exit.

389 + this version of Git and exit.

390

391 --info-path::

392 Print the path where the Info files documenting this

393 - version of git are installed and exit.

393 + version of Git are installed and exit.

394

395 -p::

396 --paginate::

@@ -400,7 +400,7 @@ help ...`.

400 below).

401

402 --no-pager::

403 - Do not pipe git output into a pager.

403 + Do not pipe Git output into a pager.

404

405 --git-dir=<path>::

406 Set the path to the repository. This can also be controlled by

@@ -416,7 +416,7 @@ help ...`.

416 more detailed discussion).

417

418 --namespace=<path>::

419 - Set the git namespace. See linkgit:gitnamespaces[7] for more

419 + Set the Git namespace. See linkgit:gitnamespaces[7] for more

420 details. Equivalent to setting the `GIT_NAMESPACE` environment

421 variable.

422

@@ -426,7 +426,7 @@ help ...`.

426 directory.

427

428 --no-replace-objects::

429 - Do not use replacement refs to replace git objects. See

429 + Do not use replacement refs to replace Git objects. See

430 linkgit:git-replace[1] for more information.

431

432 --literal-pathspecs::

@@ -438,7 +438,7 @@ help ...`.

438 GIT COMMANDS

439 ------------

440

441 -We divide git into high level ("porcelain") commands and low level

441 +We divide Git into high level ("porcelain") commands and low level

442 ("plumbing") commands.

443

444 High-level commands (porcelain)

@@ -475,7 +475,7 @@ include::cmds-foreignscminterface.txt[]

475 Low-level commands (plumbing)

476 -----------------------------

477

478 -Although git includes its

478 +Although Git includes its

479 own porcelain layer, its low-level commands are sufficient to support

480 development of alternative porcelains. Developers of such porcelains

481 might start by reading about linkgit:git-update-index[1] and

@@ -596,7 +596,7 @@ Identifier Terminology

596

597 Symbolic Identifiers

598 --------------------

599 -Any git command accepting any <object> can also use the following

599 +Any Git command accepting any <object> can also use the following

600 symbolic notation:

601

602 HEAD::

@@ -632,13 +632,13 @@ Please see linkgit:gitglossary[7].

632

633 Environment Variables

634 ---------------------

635 -Various git commands use the following environment variables:

635 +Various Git commands use the following environment variables:

636

637 -The git Repository

637 +The Git Repository

638 ~~~~~~~~~~~~~~~~~~

639 -These environment variables apply to 'all' core git commands. Nb: it

639 +These environment variables apply to 'all' core Git commands. Nb: it

640 is worth noting that they may be used/overridden by SCMS sitting above

641 -git so take care if using Cogito etc.

641 +Git so take care if using Cogito etc.

642

643 'GIT_INDEX_FILE'::

644 This environment allows the specification of an alternate

@@ -652,10 +652,10 @@ git so take care if using Cogito etc.

652 directory is used.

653

654 'GIT_ALTERNATE_OBJECT_DIRECTORIES'::

655 - Due to the immutable nature of git objects, old objects can be

655 + Due to the immutable nature of Git objects, old objects can be

656 archived into shared, read-only directories. This variable

657 specifies a ":" separated (on Windows ";" separated) list

658 - of git object directories which can be used to search for git

658 + of Git object directories which can be used to search for Git

659 objects. New objects will not be written to these directories.

660

661 'GIT_DIR'::

@@ -672,12 +672,12 @@ git so take care if using Cogito etc.

672 option and the core.worktree configuration variable.

673

674 'GIT_NAMESPACE'::

675 - Set the git namespace; see linkgit:gitnamespaces[7] for details.

675 + Set the Git namespace; see linkgit:gitnamespaces[7] for details.

676 The '--namespace' command-line option also sets this value.

677

678 'GIT_CEILING_DIRECTORIES'::

679 This should be a colon-separated list of absolute paths.

680 - If set, it is a list of directories that git should not chdir

680 + If set, it is a list of directories that Git should not chdir

681 up into while looking for a repository directory.

682 It will not exclude the current working directory or

683 a GIT_DIR set on the command line or in the environment.

@@ -685,15 +685,15 @@ git so take care if using Cogito etc.

685

686 'GIT_DISCOVERY_ACROSS_FILESYSTEM'::

687 When run in a directory that does not have ".git" repository

688 - directory, git tries to find such a directory in the parent

688 + directory, Git tries to find such a directory in the parent

689 directories to find the top of the working tree, but by default it

690 does not cross filesystem boundaries. This environment variable

691 - can be set to true to tell git not to stop at filesystem

691 + can be set to true to tell Git not to stop at filesystem

692 boundaries. Like 'GIT_CEILING_DIRECTORIES', this will not affect

693 an explicit repository directory set via 'GIT_DIR' or on the

694 command line.

695

696 -git Commits

696 +Git Commits

697 ~~~~~~~~~~~

698 'GIT_AUTHOR_NAME'::

699 'GIT_AUTHOR_EMAIL'::

@@ -704,13 +704,13 @@ git Commits

704 'EMAIL'::

705 see linkgit:git-commit-tree[1]

706

707 -git Diffs

707 +Git Diffs

708 ~~~~~~~~~

709 'GIT_DIFF_OPTS'::

710 Only valid setting is "--unified=??" or "-u??" to set the

711 number of context lines shown when a unified diff is created.

712 This takes precedence over any "-U" or "--unified" option

713 - value passed on the git diff command line.

713 + value passed on the Git diff command line.

714

715 'GIT_EXTERNAL_DIFF'::

716 When the environment variable 'GIT_EXTERNAL_DIFF' is set, the

@@ -745,13 +745,13 @@ other

745

746 'GIT_PAGER'::

747 This environment variable overrides `$PAGER`. If it is set

748 - to an empty string or to the value "cat", git will not launch

748 + to an empty string or to the value "cat", Git will not launch

749 a pager. See also the `core.pager` option in

750 linkgit:git-config[1].

751

752 'GIT_EDITOR'::

753 This environment variable overrides `$EDITOR` and `$VISUAL`.

754 - It is used by several git commands when, on interactive mode,

754 + It is used by several Git commands when, on interactive mode,

755 an editor is to be launched. See also linkgit:git-var[1]

756 and the `core.editor` option in linkgit:git-config[1].

757

@@ -772,7 +772,7 @@ personal `.ssh/config` file. Please consult your ssh documentation

772 for further details.

773

774 'GIT_ASKPASS'::

775 - If this environment variable is set, then git commands which need to

775 + If this environment variable is set, then Git commands which need to

776 acquire passwords or passphrases (e.g. for HTTP or IMAP authentication)

777 will call this program with a suitable prompt as command line argument

778 and read the password from its STDOUT. See also the 'core.askpass'

@@ -793,30 +793,30 @@ for further details.

793 after each commit-oriented record have been flushed. If this

794 variable is set to "0", the output of these commands will be done

795 using completely buffered I/O. If this environment variable is

796 - not set, git will choose buffered or record-oriented flushing

796 + not set, Git will choose buffered or record-oriented flushing

797 based on whether stdout appears to be redirected to a file or not.

798

799 'GIT_TRACE'::

800 If this variable is set to "1", "2" or "true" (comparison

801 - is case insensitive), git will print `trace:` messages on

801 + is case insensitive), Git will print `trace:` messages on

802 stderr telling about alias expansion, built-in command

803 execution and external command execution.

804 If this variable is set to an integer value greater than 1

805 - and lower than 10 (strictly) then git will interpret this

805 + and lower than 10 (strictly) then Git will interpret this

806 value as an open file descriptor and will try to write the

807 trace messages into this file descriptor.

808 Alternatively, if this variable is set to an absolute path

809 - (starting with a '/' character), git will interpret this

809 + (starting with a '/' character), Git will interpret this

810 as a file path and will try to write the trace messages

811 into it.

812

813 GIT_LITERAL_PATHSPECS::

814 - Setting this variable to `1` will cause git to treat all

814 + Setting this variable to `1` will cause Git to treat all

815 pathspecs literally, rather than as glob patterns. For example,

816 running `GIT_LITERAL_PATHSPECS=1 git log -- '*.c'` will search

817 for commits that touch the path `*.c`, not any paths that the

818 glob `*.c` matches. You might want this if you are feeding

819 - literal paths to git (e.g., paths previously given to you by

819 + literal paths to Git (e.g., paths previously given to you by

820 `git ls-tree`, `--raw` diff output, etc).

821

822

@@ -824,10 +824,10 @@ Discussion[[Discussion]]

824 ------------------------

825

826 More detail on the following is available from the

827 -link:user-manual.html#git-concepts[git concepts chapter of the

827 +link:user-manual.html#git-concepts[Git concepts chapter of the

828 user-manual] and linkgit:gitcore-tutorial[7].

829

830 -A git project normally consists of a working directory with a ".git"

830 +A Git project normally consists of a working directory with a ".git"

831 subdirectory at the top level. The .git directory contains, among other

832 things, a compressed object database representing the complete history

833 of the project, an "index" file which links that history to the current

@@ -877,12 +877,12 @@ FURTHER DOCUMENTATION

877 ---------------------

878

879 See the references in the "description" section to get started

880 -using git. The following is probably more detail than necessary

880 +using Git. The following is probably more detail than necessary

881 for a first-time user.

882

883 -The link:user-manual.html#git-concepts[git concepts chapter of the

883 +The link:user-manual.html#git-concepts[Git concepts chapter of the

884 user-manual] and linkgit:gitcore-tutorial[7] both provide

885 -introductions to the underlying git architecture.

885 +introductions to the underlying Git architecture.

886

887 See linkgit:gitworkflows[7] for an overview of recommended workflows.

888

@@ -899,7 +899,7 @@ read linkgit:gitcvs-migration[7].

899 Authors

900 -------

901 Git was started by Linus Torvalds, and is currently maintained by Junio

902 -C Hamano. Numerous contributions have come from the git mailing list

902 +C Hamano. Numerous contributions have come from the Git mailing list

903 <git@vger.kernel.org>. http://www.ohloh.net/p/git/contributors/summary

904 gives you a more complete list of contributors.

905

Documentation/gitattributes.txt

+36 -36

@@ -58,7 +58,7 @@ attribute. The rules how the pattern matches paths are the

58 same as in `.gitignore` files; see linkgit:gitignore[5].

59 Unlike `.gitignore`, negative patterns are forbidden.

61 -When deciding what attributes are assigned to a path, git

61 +When deciding what attributes are assigned to a path, Git

62 consults `$GIT_DIR/info/attributes` file (which has the highest

63 precedence), `.gitattributes` file in the same directory as the

64 path in question, and its parent directories up to the toplevel of the

@@ -94,7 +94,7 @@ the name of the attribute prefixed with an exclamation point `!`.

94 EFFECTS

95 -------

97 -Certain operations by git can be influenced by assigning

97 +Certain operations by Git can be influenced by assigning

98 particular attributes to a path. Currently, the following

99 operations are attributes-aware.

100

@@ -104,7 +104,7 @@ Checking-out and checking-in

104 These attributes affect how the contents stored in the

105 repository are copied to the working tree files when commands

106 such as 'git checkout' and 'git merge' run. They also affect how

107 -git stores the contents you prepare in the working tree in the

107 +Git stores the contents you prepare in the working tree in the

108 repository upon 'git add' and 'git commit'.

109

110 `text`

@@ -124,22 +124,22 @@ Set::

124

125 Unset::

126

127 - Unsetting the `text` attribute on a path tells git not to

127 + Unsetting the `text` attribute on a path tells Git not to

128 attempt any end-of-line conversion upon checkin or checkout.

129

130 Set to string value "auto"::

131

132 When `text` is set to "auto", the path is marked for automatic

133 - end-of-line normalization. If git decides that the content is

133 + end-of-line normalization. If Git decides that the content is

134 text, its line endings are normalized to LF on checkin.

135

136 Unspecified::

137

138 - If the `text` attribute is unspecified, git uses the

138 + If the `text` attribute is unspecified, Git uses the

139 `core.autocrlf` configuration variable to determine if the

140 file should be converted.

141

142 -Any other value causes git to act as if `text` has been left

142 +Any other value causes Git to act as if `text` has been left

143 unspecified.

144

145 `eol`

@@ -151,13 +151,13 @@ content checks, effectively setting the `text` attribute.

151

152 Set to string value "crlf"::

153

154 - This setting forces git to normalize line endings for this

154 + This setting forces Git to normalize line endings for this

155 file on checkin and convert them to CRLF when the file is

156 checked out.

157

158 Set to string value "lf"::

159

160 - This setting forces git to normalize line endings to LF on

160 + This setting forces Git to normalize line endings to LF on

161 checkin and prevents conversion to CRLF when the file is

162 checked out.

163

@@ -176,11 +176,11 @@ crlf=input eol=lf

176 End-of-line conversion

177 ^^^^^^^^^^^^^^^^^^^^^^

178

179 -While git normally leaves file contents alone, it can be configured to

179 +While Git normally leaves file contents alone, it can be configured to

180 normalize line endings to LF in the repository and, optionally, to

181 convert them to CRLF when files are checked out.

182

183 -Here is an example that will make git normalize .txt, .vcproj and .sh

183 +Here is an example that will make Git normalize .txt, .vcproj and .sh

184 files, ensure that .vcproj files have CRLF and .sh files have LF in

185 the working directory, and prevent .jpg files from being normalized

186 regardless of their content.

@@ -194,7 +194,7 @@ regardless of their content.

194

195 Other source code management systems normalize all text files in their

196 repositories, and there are two ways to enable similar automatic

197 -normalization in git.

197 +normalization in Git.

198

199 If you simply want to have CRLF line endings in your working directory

200 regardless of the repository you are working with, you can set the

@@ -219,9 +219,9 @@ attribute to "auto" for _all_ files.

219 * text=auto

220 ------------------------

221

222 -This ensures that all files that git considers to be text will have

222 +This ensures that all files that Git considers to be text will have

223 normalized (LF) line endings in the repository. The `core.eol`

224 -configuration variable controls which line endings git will use for

224 +configuration variable controls which line endings Git will use for

225 normalized files in your working directory; the default is to use the

226 native line ending for your platform, or CRLF if `core.autocrlf` is

227 set.

@@ -234,7 +234,7 @@ directory:

234

235 -------------------------------------------------

236 $ echo "* text=auto" >>.gitattributes

237 -$ rm .git/index # Remove the index to force git to

237 +$ rm .git/index # Remove the index to force Git to

238 $ git reset # re-scan the working directory

239 $ git status # Show files that will be normalized

240 $ git add -u

@@ -249,17 +249,17 @@ unset their `text` attribute before running 'git add -u'.

249 manual.pdf -text

250 ------------------------

251

252 -Conversely, text files that git does not detect can have normalization

252 +Conversely, text files that Git does not detect can have normalization

253 enabled manually.

254

255 ------------------------

256 weirdchars.txt text

257 ------------------------

258

259 -If `core.safecrlf` is set to "true" or "warn", git verifies if

259 +If `core.safecrlf` is set to "true" or "warn", Git verifies if

260 the conversion is reversible for the current setting of

261 -`core.autocrlf`. For "true", git rejects irreversible

262 -conversions; for "warn", git only prints a warning but accepts

261 +`core.autocrlf`. For "true", Git rejects irreversible

262 +conversions; for "warn", Git only prints a warning but accepts

263 an irreversible conversion. The safety triggers to prevent such

264 a conversion done to the files in the work tree, but there are a

265 few exceptions. Even though...

@@ -280,7 +280,7 @@ few exceptions. Even though...

280 `ident`

281 ^^^^^^^

282

283 -When the attribute `ident` is set for a path, git replaces

283 +When the attribute `ident` is set for a path, Git replaces

284 `$Id$` in the blob object with `$Id:`, followed by the

285 40-character hexadecimal blob object name, followed by a dollar

286 sign `$` upon checkout. Any byte sequence that begins with

@@ -311,7 +311,7 @@ the appropriate filter program, the project should still be usable.

311

312 Another use of the content filtering is to store the content that cannot

313 be directly used in the repository (e.g. a UUID that refers to the true

314 -content stored outside git, or an encrypted content) and turn it into a

314 +content stored outside Git, or an encrypted content) and turn it into a

315 usable form upon checkout (e.g. download the external content, or decrypt

316 the encrypted content).

317

@@ -397,7 +397,7 @@ clean/smudge filter or text/eol/ident attributes, merging anything

397 where the attribute is not in place would normally cause merge

398 conflicts.

399

400 -To prevent these unnecessary merge conflicts, git can be told to run a

400 +To prevent these unnecessary merge conflicts, Git can be told to run a

401 virtual check-out and check-in of all three stages of a file when

402 resolving a three-way merge by setting the `merge.renormalize`

403 configuration variable. This prevents changes caused by check-in

@@ -417,11 +417,11 @@ Generating diff text

417 `diff`

418 ^^^^^^

419

420 -The attribute `diff` affects how 'git' generates diffs for particular

421 -files. It can tell git whether to generate a textual patch for the path

420 +The attribute `diff` affects how Git generates diffs for particular

421 +files. It can tell Git whether to generate a textual patch for the path

422 or to treat the path as a binary file. It can also affect what line is

423 -shown on the hunk header `@@ -k,l +n,m @@` line, tell git to use an

424 -external command to generate the diff, or ask git to convert binary

423 +shown on the hunk header `@@ -k,l +n,m @@` line, tell Git to use an

424 +external command to generate the diff, or ask Git to convert binary

425 files to a text format before generating the diff.

426

427 Set::

@@ -449,7 +449,7 @@ String::

449 specify one or more options, as described in the following

450 section. The options for the diff driver "foo" are defined

451 by the configuration variables in the "diff.foo" section of the

452 - git config file.

452 + Git config file.

453

454

455 Defining an external diff driver

@@ -467,7 +467,7 @@ To define an external diff driver `jcdiff`, add a section to your

467 command = j-c-diff

468 ----------------------------------------------------------------

469

470 -When git needs to show you a diff for the path with `diff`

470 +When Git needs to show you a diff for the path with `diff`

471 attribute set to `jcdiff`, it calls the command you specified

472 with the above configuration, i.e. `j-c-diff`, with 7

473 parameters, just like `GIT_EXTERNAL_DIFF` program is called.

@@ -606,7 +606,7 @@ should generate it separately and send it as a comment _in

606 addition to_ the usual binary diff that you might send.

607

608 Because text conversion can be slow, especially when doing a

609 -large number of them with `git log -p`, git provides a mechanism

609 +large number of them with `git log -p`, Git provides a mechanism

610 to cache the output and use it in future diffs. To enable

611 caching, set the "cachetextconv" variable in your diff driver's

612 config. For example:

@@ -619,7 +619,7 @@ config. For example:

619

620 This will cache the result of running "exif" on each blob

621 indefinitely. If you change the textconv config variable for a

622 -diff driver, git will automatically invalidate the cache entries

622 +diff driver, Git will automatically invalidate the cache entries

623 and re-run the textconv filter. If you want to invalidate the

624 cache manually (e.g., because your version of "exif" was updated

625 and now produces better output), you can remove the cache

@@ -640,7 +640,7 @@ output to resemble unified diff. You are free to locate and report

640 changes in the most appropriate way for your data format.

641

642 A textconv, by comparison, is much more limiting. You provide a

643 -transformation of the data into a line-oriented text format, and git

643 +transformation of the data into a line-oriented text format, and Git

644 uses its regular diff tools to generate the output. There are several

645 advantages to choosing this method:

646

@@ -650,7 +650,7 @@ advantages to choosing this method:

650 odt2txt).

651

652 2. Git diff features. By performing only the transformation step

653 - yourself, you can still utilize many of git's diff features,

653 + yourself, you can still utilize many of Git's diff features,

654 including colorization, word-diff, and combined diffs for merges.

655

656 3. Caching. Textconv caching can speed up repeated diffs, such as those

@@ -675,7 +675,7 @@ attribute in the `.gitattributes` file:

675 *.ps -diff

676 ------------------------

677

678 -This will cause git to generate `Binary files differ` (or a binary

678 +This will cause Git to generate `Binary files differ` (or a binary

679 patch, if binary patches are enabled) instead of a regular diff.

680

681 However, one may also want to specify other diff driver attributes. For

@@ -831,7 +831,7 @@ control per path.

831

832 Set::

833

834 - Notice all types of potential whitespace errors known to git.

834 + Notice all types of potential whitespace errors known to Git.

835 The tab width is taken from the value of the `core.whitespace`

836 configuration variable.

837

@@ -863,7 +863,7 @@ archive files.

863 `export-subst`

864 ^^^^^^^^^^^^^^

865

866 -If the attribute `export-subst` is set for a file then git will expand

866 +If the attribute `export-subst` is set for a file then Git will expand

867 several placeholders when adding this file to an archive. The

868 expansion depends on the availability of a commit ID, i.e., if

869 linkgit:git-archive[1] has been given a tree instead of a commit or a

@@ -961,7 +961,7 @@ abc -foo -bar

961 the attributes given to path `t/abc` are computed as follows:

962

963 1. By examining `t/.gitattributes` (which is in the same

964 - directory as the path in question), git finds that the first

964 + directory as the path in question), Git finds that the first

965 line matches. `merge` attribute is set. It also finds that

966 the second line matches, and attributes `foo` and `bar`

967 are unset.

Documentation/gitcli.txt

+7 -7

@@ -3,7 +3,7 @@ gitcli(7)

4 NAME

5 ----

6 -gitcli - git command line interface and conventions

6 +gitcli - Git command line interface and conventions

8 SYNOPSIS

9 --------

@@ -13,7 +13,7 @@ gitcli

13 DESCRIPTION

14 -----------

16 -This manual describes the convention used throughout git CLI.

16 +This manual describes the convention used throughout Git CLI.

18 Many commands take revisions (most often "commits", but sometimes

19 "tree-ish", depending on the context and command) and paths as their

@@ -32,7 +32,7 @@ arguments. Here are the rules:

32 between the HEAD commit and the work tree as a whole". You can say

33 `git diff HEAD --` to ask for the latter.

35 - * Without disambiguating `--`, git makes a reasonable guess, but errors

35 + * Without disambiguating `--`, Git makes a reasonable guess, but errors

36 out and asking you to disambiguate when ambiguous. E.g. if you have a

37 file called HEAD in your work tree, `git diff HEAD` is ambiguous, and

38 you have to say either `git diff HEAD --` or `git diff -- HEAD` to

@@ -60,9 +60,9 @@ see `hello.c` in your working tree with the former, but with the latter

60 you will.

62 Here are the rules regarding the "flags" that you should follow when you are

63 -scripting git:

63 +scripting Git:

65 - * it's preferred to use the non dashed form of git commands, which means that

65 + * it's preferred to use the non dashed form of Git commands, which means that

66 you should prefer `git foo` to `git-foo`.

68 * splitting short options to separate words (prefer `git foo -a -b`

@@ -90,7 +90,7 @@ scripting git:

91 ENHANCED OPTION PARSER

92 ----------------------

93 -From the git 1.5.4 series and further, many git commands (not all of them at the

93 +From the Git 1.5.4 series and further, many Git commands (not all of them at the

94 time of the writing though) come with an enhanced option parser.

96 Here is a list of the facilities provided by this option parser.

@@ -117,7 +117,7 @@ usage: git describe [options] <committish>*

117 ---------------------------------------------

118

119 --help-all::

120 - Some git commands take options that are only used for plumbing or that

120 + Some Git commands take options that are only used for plumbing or that

121 are deprecated, and such options are hidden from the default usage. This

122 option gives the full list of options.

123

Documentation/gitcore-tutorial.txt

+75 -75

@@ -3,7 +3,7 @@ gitcore-tutorial(7)

4 NAME

5 ----

6 -gitcore-tutorial - A git core tutorial for developers

6 +gitcore-tutorial - A Git core tutorial for developers

8 SYNOPSIS

9 --------

@@ -12,17 +12,17 @@ git *

12 DESCRIPTION

13 -----------

15 -This tutorial explains how to use the "core" git commands to set up and

16 -work with a git repository.

15 +This tutorial explains how to use the "core" Git commands to set up and

16 +work with a Git repository.

18 -If you just need to use git as a revision control system you may prefer

18 +If you just need to use Git as a revision control system you may prefer

19 to start with "A Tutorial Introduction to Git" (linkgit:gittutorial[7]) or

20 link:user-manual.html[the Git User Manual].

22 However, an understanding of these low-level tools can be helpful if

23 -you want to understand git's internals.

23 +you want to understand Git's internals.

25 -The core git is often called "plumbing", with the prettier user

25 +The core Git is often called "plumbing", with the prettier user

26 interfaces on top of it called "porcelain". You may not want to use the

27 plumbing directly very often, but it can be good to know what the

28 plumbing does for when the porcelain isn't flushing.

@@ -40,19 +40,19 @@ Deeper technical details are often marked as Notes, which you can

40 skip on your first reading.

43 -Creating a git repository

43 +Creating a Git repository

44 -------------------------

46 -Creating a new git repository couldn't be easier: all git repositories start

46 +Creating a new Git repository couldn't be easier: all Git repositories start

47 out empty, and the only thing you need to do is find yourself a

48 subdirectory that you want to use as a working tree - either an empty

49 one for a totally new project, or an existing working tree that you want

50 -to import into git.

50 +to import into Git.

52 For our first example, we're going to start a totally new repository from

53 scratch, with no pre-existing files, and we'll call it 'git-tutorial'.

54 To start up, create a subdirectory for it, change into that

55 -subdirectory, and initialize the git infrastructure with 'git init':

55 +subdirectory, and initialize the Git infrastructure with 'git init':

57 ------------------------------------------------

58 $ mkdir git-tutorial

@@ -60,13 +60,13 @@ $ cd git-tutorial

60 $ git init

61 ------------------------------------------------

63 -to which git will reply

63 +to which Git will reply

65 ----------------

66 Initialized empty Git repository in .git/

67 ----------------

69 -which is just git's way of saying that you haven't been doing anything

69 +which is just Git's way of saying that you haven't been doing anything

70 strange, and that it will have created a local `.git` directory setup for

71 your new project. You will now have a `.git` directory, and you can

72 inspect that with 'ls'. For your new empty project, it should show you

@@ -102,7 +102,7 @@ start out expecting to work on the `master` branch.

102

103 However, this is only a convention, and you can name your branches

104 anything you want, and don't have to ever even 'have' a `master`

105 -branch. A number of the git tools will assume that `.git/HEAD` is

105 +branch. A number of the Git tools will assume that `.git/HEAD` is

106 valid, though.

107

108 [NOTE]

@@ -119,18 +119,18 @@ populating your tree.

119 An advanced user may want to take a look at linkgit:gitrepository-layout[5]

120 after finishing this tutorial.

121

122 -You have now created your first git repository. Of course, since it's

122 +You have now created your first Git repository. Of course, since it's

123 empty, that's not very useful, so let's start populating it with data.

124

125

126 -Populating a git repository

126 +Populating a Git repository

127 ---------------------------

128

129 We'll keep this simple and stupid, so we'll start off with populating a

130 few trivial files just to get a feel for it.

131

132 Start off with just creating any random files that you want to maintain

133 -in your git repository. We'll start off with a few bad examples, just to

133 +in your Git repository. We'll start off with a few bad examples, just to

134 get a feel for how this works:

135

136 ------------------------------------------------

@@ -146,7 +146,7 @@ but to actually check in your hard work, you will have to go through two steps:

146

147 - commit that index file as an object.

148

149 -The first step is trivial: when you want to tell git about any changes

149 +The first step is trivial: when you want to tell Git about any changes

150 to your working tree, you use the 'git update-index' program. That

151 program normally just takes a list of filenames you want to update, but

152 to avoid trivial mistakes, it refuses to add new entries to the index

@@ -160,10 +160,10 @@ So to populate the index with the two files you just created, you can do

160 $ git update-index --add hello example

161 ------------------------------------------------

162

163 -and you have now told git to track those two files.

163 +and you have now told Git to track those two files.

164

165 In fact, as you did that, if you now look into your object directory,

166 -you'll notice that git will have added two new objects to the object

166 +you'll notice that Git will have added two new objects to the object

167 database. If you did exactly the steps above, you should now be able to do

168

169

@@ -189,7 +189,7 @@ $ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238

189 ----------------

190

191 where the `-t` tells 'git cat-file' to tell you what the "type" of the

192 -object is. git will tell you that you have a "blob" object (i.e., just a

192 +object is. Git will tell you that you have a "blob" object (i.e., just a

193 regular file), and you can see the contents with

194

195 ----------------

@@ -214,28 +214,28 @@ Anyway, as we mentioned previously, you normally never actually take a

214 look at the objects themselves, and typing long 40-character hex

215 names is not something you'd normally want to do. The above digression

216 was just to show that 'git update-index' did something magical, and

217 -actually saved away the contents of your files into the git object

217 +actually saved away the contents of your files into the Git object

218 database.

219

220 Updating the index did something else too: it created a `.git/index`

221 file. This is the index that describes your current working tree, and

222 something you should be very aware of. Again, you normally never worry

223 about the index file itself, but you should be aware of the fact that

224 -you have not actually really "checked in" your files into git so far,

225 -you've only *told* git about them.

224 +you have not actually really "checked in" your files into Git so far,

225 +you've only *told* Git about them.

226

227 -However, since git knows about them, you can now start using some of the

228 -most basic git commands to manipulate the files or look at their status.

227 +However, since Git knows about them, you can now start using some of the

228 +most basic Git commands to manipulate the files or look at their status.

229

230 -In particular, let's not even check in the two files into git yet, we'll

230 +In particular, let's not even check in the two files into Git yet, we'll

231 start off by adding another line to `hello` first:

232

233 ------------------------------------------------

234 $ echo "It's a new day for git" >>hello

235 ------------------------------------------------

236

237 -and you can now, since you told git about the previous state of `hello`, ask

238 -git what has changed in the tree compared to your old index, using the

237 +and you can now, since you told Git about the previous state of `hello`, ask

238 +Git what has changed in the tree compared to your old index, using the

239 'git diff-files' command:

240

241 ------------

@@ -282,11 +282,11 @@ index 557db03..263414f 100644

282 ------------

283

284

285 -Committing git state

285 +Committing Git state

286 --------------------

287

288 -Now, we want to go to the next stage in git, which is to take the files

289 -that git knows about in the index, and commit them as a real tree. We do

288 +Now, we want to go to the next stage in Git, which is to take the files

289 +that Git knows about in the index, and commit them as a real tree. We do

290 that in two phases: creating a 'tree' object, and committing that 'tree'

291 object as a 'commit' object together with an explanation of what the

292 tree was all about, along with information of how we came to that state.

@@ -296,7 +296,7 @@ There are no options or other input: `git write-tree` will take the

296 current index state, and write an object that describes that whole

297 index. In other words, we're now tying together all the different

298 filenames with their contents (and their permissions), and we're

299 -creating the equivalent of a git "directory" object:

299 +creating the equivalent of a Git "directory" object:

300

301 ------------------------------------------------

302 $ git write-tree

@@ -415,9 +415,9 @@ regardless of whether the `--cached` flag is used or not. The `--cached`

415 flag really only determines whether the file *contents* to be compared

416 come from the working tree or not.

417

418 -This is not hard to understand, as soon as you realize that git simply

418 +This is not hard to understand, as soon as you realize that Git simply

419 never knows (or cares) about files that it is not told about

420 -explicitly. git will never go *looking* for files to compare, it

420 +explicitly. Git will never go *looking* for files to compare, it

421 expects you to tell it what the files are, and that's what the index

422 is there for.

423 ================

@@ -433,7 +433,7 @@ update the index cache:

433 $ git update-index hello

434 ------------------------------------------------

435

436 -(note how we didn't need the `--add` flag this time, since git knew

436 +(note how we didn't need the `--add` flag this time, since Git knew

437 about the file already).

438

439 Note what happens to the different 'git diff-{asterisk}' versions here.

@@ -464,7 +464,7 @@ this point (you can continue to edit things and update the index), you

464 can just leave an empty message. Otherwise `git commit` will commit

465 the change for you.

466

467 -You've now made your first real git commit. And if you're interested in

467 +You've now made your first real Git commit. And if you're interested in

468 looking at what `git commit` really does, feel free to investigate:

469 it's a few very simple shell scripts to generate the helpful (?) commit

470 message headers, and a few one-liners that actually do the

@@ -535,7 +535,7 @@ all, but just show the actual commit message.

535 In fact, together with the 'git rev-list' program (which generates a

536 list of revisions), 'git diff-tree' ends up being a veritable fount of

537 changes. A trivial (but very useful) script called 'git whatchanged' is

538 -included with git which does exactly this, and shows a log of recent

538 +included with Git which does exactly this, and shows a log of recent

539 activities.

540

541 To see the whole history of our pitiful little git-tutorial project, you

@@ -563,19 +563,19 @@ the log.showroot configuration variable to false. Having this, you

563 can still show it for each command just adding the `--root` option,

564 which is a flag for 'git diff-tree' accepted by both commands.

565

566 -With that, you should now be having some inkling of what git does, and

566 +With that, you should now be having some inkling of what Git does, and

567 can explore on your own.

568

569 [NOTE]

570 Most likely, you are not directly using the core

571 -git Plumbing commands, but using Porcelain such as 'git add', `git-rm'

571 +Git Plumbing commands, but using Porcelain such as 'git add', `git-rm'

572 and `git-commit'.

573

574

575 Tagging a version

576 -----------------

577

578 -In git, there are two kinds of tags, a "light" one, and an "annotated tag".

578 +In Git, there are two kinds of tags, a "light" one, and an "annotated tag".

579

580 A "light" tag is technically nothing more than a branch, except we put

581 it in the `.git/refs/tags/` subdirectory instead of calling it a `head`.

@@ -598,7 +598,7 @@ obviously be an empty diff, but if you continue to develop and commit

598 stuff, you can use your tag as an "anchor-point" to see what has changed

599 since you tagged it.

600

601 -An "annotated tag" is actually a real git object, and contains not only a

601 +An "annotated tag" is actually a real Git object, and contains not only a

602 pointer to the state you want to tag, but also a small tag name and

603 message, along with optionally a PGP signature that says that yes,

604 you really did

@@ -623,17 +623,17 @@ name for the state at that point.

623 Copying repositories

624 --------------------

625

626 -git repositories are normally totally self-sufficient and relocatable.

626 +Git repositories are normally totally self-sufficient and relocatable.

627 Unlike CVS, for example, there is no separate notion of

628 -"repository" and "working tree". A git repository normally *is* the

629 -working tree, with the local git information hidden in the `.git`

628 +"repository" and "working tree". A Git repository normally *is* the

629 +working tree, with the local Git information hidden in the `.git`

630 subdirectory. There is nothing else. What you see is what you got.

631

632 [NOTE]

633 -You can tell git to split the git internal information from

633 +You can tell Git to split the Git internal information from

634 the directory that it tracks, but we'll ignore that for now: it's not

635 how normal projects work, and it's really only meant for special uses.

636 -So the mental model of "the git information is always tied directly to

636 +So the mental model of "the Git information is always tied directly to

637 the working tree that it describes" may not be technically 100%

638 accurate, but it's a good model for all normal use.

639

@@ -649,13 +649,13 @@ $ rm -rf git-tutorial

649 and it will be gone. There's no external repository, and there's no

650 history outside the project you created.

651

652 - - if you want to move or duplicate a git repository, you can do so. There

652 + - if you want to move or duplicate a Git repository, you can do so. There

653 is 'git clone' command, but if all you want to do is just to

654 create a copy of your repository (with all the full history that

655 went along with it), you can do so with a regular

656 `cp -a git-tutorial new-git-tutorial`.

657 +

658 -Note that when you've moved or copied a git repository, your git index

658 +Note that when you've moved or copied a Git repository, your Git index

659 file (which caches various information, notably some of the "stat"

660 information for the files involved) will likely need to be refreshed.

661 So after you do a `cp -a` to create a new copy, you'll want to do

@@ -667,7 +667,7 @@ $ git update-index --refresh

667 in the new repository to make sure that the index file is up-to-date.

668

669 Note that the second point is true even across machines. You can

670 -duplicate a remote git repository with *any* regular copy mechanism, be it

670 +duplicate a remote Git repository with *any* regular copy mechanism, be it

671 'scp', 'rsync' or 'wget'.

672

673 When copying a remote repository, you'll want to at a minimum update the

@@ -694,23 +694,23 @@ The above can also be written as simply

694 $ git reset

695 ----------------

696

697 -and in fact a lot of the common git command combinations can be scripted

697 +and in fact a lot of the common Git command combinations can be scripted

698 with the `git xyz` interfaces. You can learn things by just looking

699 at what the various git scripts do. For example, `git reset` used to be

700 the above two lines implemented in 'git reset', but some things like

701 'git status' and 'git commit' are slightly more complex scripts around

702 -the basic git commands.

702 +the basic Git commands.

703

704 Many (most?) public remote repositories will not contain any of

705 the checked out files or even an index file, and will *only* contain the

706 -actual core git files. Such a repository usually doesn't even have the

707 -`.git` subdirectory, but has all the git files directly in the

706 +actual core Git files. Such a repository usually doesn't even have the

707 +`.git` subdirectory, but has all the Git files directly in the

708 repository.

709

710 -To create your own local live copy of such a "raw" git repository, you'd

710 +To create your own local live copy of such a "raw" Git repository, you'd

711 first create your own subdirectory for the project, and then copy the

712 raw repository contents into the `.git` directory. For example, to

713 -create your own copy of the git repository, you'd do the following

713 +create your own copy of the Git repository, you'd do the following

714

715 ----------------

716 $ mkdir my-git

@@ -725,7 +725,7 @@ $ git read-tree HEAD

725 ----------------

726

727 to populate the index. However, now you have populated the index, and

728 -you have all the git internal files, but you will notice that you don't

728 +you have all the Git internal files, but you will notice that you don't

729 actually have any of the working tree files to work on. To get

730 those, you'd check them out with

731

@@ -757,7 +757,7 @@ repository, and checked it out.

757 Creating a new branch

758 ---------------------

759

760 -Branches in git are really nothing more than pointers into the git

760 +Branches in Git are really nothing more than pointers into the Git

761 object database from within the `.git/refs/` subdirectory, and as we

762 already discussed, the `HEAD` branch is nothing but a symlink to one of

763 these object pointers.

@@ -849,7 +849,7 @@ $ git commit -m "Some work." -i hello

849 Here, we just added another line to `hello`, and we used a shorthand for

850 doing both `git update-index hello` and `git commit` by just giving the

851 filename directly to `git commit`, with an `-i` flag (it tells

852 -git to 'include' that file in addition to what you have done to

852 +Git to 'include' that file in addition to what you have done to

853 the index file so far when making the commit). The `-m` flag is to give the

854 commit log message from the command line.

855

@@ -900,7 +900,7 @@ where the first argument is going to be used as the commit message if

900 the merge can be resolved automatically.

901

902 Now, in this case we've intentionally created a situation where the

903 -merge will need to be fixed up by hand, though, so git will do as much

903 +merge will need to be fixed up by hand, though, so Git will do as much

904 of it as it can automatically (which in this case is just merge the `example`

905 file, which had no differences in the `mybranch` branch), and say:

906

@@ -939,7 +939,7 @@ After you're done, start up `gitk --all` to see graphically what the

939 history looks like. Notice that `mybranch` still exists, and you can

940 switch to it, and continue to work with it if you want to. The

941 `mybranch` branch will not contain the merge, but next time you merge it

942 -from the `master` branch, git will know how you merged it, so you'll not

942 +from the `master` branch, Git will know how you merged it, so you'll not

943 have to do _that_ merge again.

944

945 Another useful tool, especially if you do not always work in X-Window

@@ -1028,7 +1028,7 @@ Merging external work

1028 ---------------------

1029

1030 It's usually much more common that you merge with somebody else than

1031 -merging with your own branches, so it's worth pointing out that git

1031 +merging with your own branches, so it's worth pointing out that Git

1032 makes that very easy too, and in fact, it's not that different from

1033 doing a 'git merge'. In fact, a remote merge ends up being nothing

1034 more than "fetch the work from a remote repository into a temporary tag"

@@ -1068,7 +1068,7 @@ and requires you to have a log-in privilege over `ssh` to the

1068 remote machine. It finds out the set of objects the other side

1069 lacks by exchanging the head commits both ends have and

1070 transfers (close to) minimum set of objects. It is by far the

1071 -most efficient way to exchange git objects between repositories.

1071 +most efficient way to exchange Git objects between repositories.

1072

1073 Local directory::

1074 `/path/to/repo.git/`

@@ -1077,7 +1077,7 @@ This transport is the same as SSH transport but uses 'sh' to run

1077 both ends on the local machine instead of running other end on

1078 the remote machine via 'ssh'.

1079

1080 -git Native::

1080 +Git Native::

1081 `git://remote.machine/path/to/repo.git/`

1082 +

1083 This transport was designed for anonymous downloading. Like SSH

@@ -1099,8 +1099,8 @@ necessary objects. Because of this behavior, they are

1099 sometimes also called 'commit walkers'.

1100 +

1101 The 'commit walkers' are sometimes also called 'dumb

1102 -transports', because they do not require any git aware smart

1103 -server like git Native transport does. Any stock HTTP server

1102 +transports', because they do not require any Git aware smart

1103 +server like Git Native transport does. Any stock HTTP server

1104 that does not even support directory index would suffice. But

1105 you must prepare your repository with 'git update-server-info'

1106 to help dumb transport downloaders.

@@ -1321,7 +1321,7 @@ update the public repository from it. This is often called

1321

1322 [NOTE]

1323 This public repository could further be mirrored, and that is

1324 -how git repositories at `kernel.org` are managed.

1324 +how Git repositories at `kernel.org` are managed.

1325

1326 Publishing the changes from your local (private) repository to

1327 your remote (public) repository requires a write privilege on

@@ -1340,7 +1340,7 @@ done only once.

1340 on the remote machine. The communication between the two over

1341 the network internally uses an SSH connection.

1342

1343 -Your private repository's git directory is usually `.git`, but

1343 +Your private repository's Git directory is usually `.git`, but

1344 your public repository is often named after the project name,

1345 i.e. `<project>.git`. Let's create such a public repository for

1346 project `my-git`. After logging into the remote machine, create

@@ -1350,7 +1350,7 @@ an empty directory:

1350 $ mkdir my-git.git

1351 ------------

1352

1353 -Then, make that directory into a git repository by running

1353 +Then, make that directory into a Git repository by running

1354 'git init', but this time, since its name is not the usual

1355 `.git`, we do things slightly differently:

1356

@@ -1389,7 +1389,7 @@ This synchronizes your public repository to match the named

1389 branch head (i.e. `master` in this case) and objects reachable

1390 from them in your current repository.

1391

1392 -As a real example, this is how I update my public git

1392 +As a real example, this is how I update my public Git

1393 repository. Kernel.org mirror network takes care of the

1394 propagation to other publicly visible machines:

1395

@@ -1402,9 +1402,9 @@ Packing your repository

1402 -----------------------

1403

1404 Earlier, we saw that one file under `.git/objects/??/` directory

1405 -is stored for each git object you create. This representation

1405 +is stored for each Git object you create. This representation

1406 is efficient to create atomically and safely, but

1407 -not so convenient to transport over the network. Since git objects are

1407 +not so convenient to transport over the network. Since Git objects are

1408 immutable once they are created, there is a way to optimize the

1409 storage by "packing them together". The command

1410

@@ -1472,14 +1472,14 @@ repositories every once in a while.

1472 Working with Others

1473 -------------------

1474

1475 -Although git is a truly distributed system, it is often

1475 +Although Git is a truly distributed system, it is often

1476 convenient to organize your project with an informal hierarchy

1477 of developers. Linux kernel development is run this way. There

1478 is a nice illustration (page 17, "Merges to Mainline") in

1479 link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation].

1480

1481 It should be stressed that this hierarchy is purely *informal*.

1482 -There is nothing fundamental in git that enforces the "chain of

1482 +There is nothing fundamental in Git that enforces the "chain of

1483 patch flow" this hierarchy implies. You do not have to pull

1484 from only one remote repository.

1485

@@ -1592,7 +1592,7 @@ Working with Others, Shared Repository Style

1592

1593 If you are coming from CVS background, the style of cooperation

1594 suggested in the previous section may be new to you. You do not

1595 -have to worry. git supports "shared public repository" style of

1595 +have to worry. Git supports "shared public repository" style of

1596 cooperation you are probably more familiar with as well.

1597

1598 See linkgit:gitcvs-migration[7] for the details.

@@ -1602,7 +1602,7 @@ Bundling your work together

1602

1603 It is likely that you will be working on more than one thing at

1604 a time. It is easy to manage those more-or-less independent tasks

1605 -using branches with git.

1605 +using branches with Git.

1606

1607 We have already seen how branches work previously,

1608 with "fun and work" example using two branches. The idea is the

Documentation/gitcredentials.txt

+12 -12

@@ -3,7 +3,7 @@ gitcredentials(7)

4 NAME

5 ----

6 -gitcredentials - providing usernames and passwords to git

6 +gitcredentials - providing usernames and passwords to Git

8 SYNOPSIS

9 --------

@@ -18,13 +18,13 @@ DESCRIPTION

18 Git will sometimes need credentials from the user in order to perform

19 operations; for example, it may need to ask for a username and password

20 in order to access a remote repository over HTTP. This manual describes

21 -the mechanisms git uses to request these credentials, as well as some

21 +the mechanisms Git uses to request these credentials, as well as some

22 features to avoid inputting these credentials repeatedly.

24 REQUESTING CREDENTIALS

25 ----------------------

27 -Without any credential helpers defined, git will try the following

27 +Without any credential helpers defined, Git will try the following

28 strategies to ask the user for usernames and passwords:

30 1. If the `GIT_ASKPASS` environment variable is set, the program

@@ -59,7 +59,7 @@ for a password. It is generally configured by adding this to your config:

59 username = me

60 ---------------------------------------

62 -Credential helpers, on the other hand, are external programs from which git can

62 +Credential helpers, on the other hand, are external programs from which Git can

63 request both usernames and passwords; they typically interface with secure

64 storage provided by the OS or other programs.

@@ -79,7 +79,7 @@ store::

79 You may also have third-party helpers installed; search for

80 `credential-*` in the output of `git help -a`, and consult the

81 documentation of individual helpers. Once you have selected a helper,

82 -you can tell git to use it by putting its name into the

82 +you can tell Git to use it by putting its name into the

83 credential.helper variable.

85 1. Find a helper.

@@ -95,7 +95,7 @@ credential-foo

95 $ git help credential-foo

96 -------------------------------------------

98 -3. Tell git to use it.

98 +3. Tell Git to use it.

99 +

100 -------------------------------------------

101 $ git config --global credential.helper foo

@@ -103,7 +103,7 @@ $ git config --global credential.helper foo

103

104 If there are multiple instances of the `credential.helper` configuration

105 variable, each helper will be tried in turn, and may provide a username,

106 -password, or nothing. Once git has acquired both a username and a

106 +password, or nothing. Once Git has acquired both a username and a

107 password, no more helpers will be tried.

108

109

@@ -114,7 +114,7 @@ Git considers each credential to have a context defined by a URL. This context

114 is used to look up context-specific configuration, and is passed to any

115 helpers, which may use it as an index into secure storage.

116

117 -For instance, imagine we are accessing `https://example.com/foo.git`. When git

117 +For instance, imagine we are accessing `https://example.com/foo.git`. When Git

118 looks into a config file to see if a section matches this context, it will

119 consider the two a match if the context is a more-specific subset of the

120 pattern in the config file. For example, if you have this in your config file:

@@ -133,10 +133,10 @@ context would not match:

133 username = foo

134 --------------------------------------

135

136 -because the hostnames differ. Nor would it match `foo.example.com`; git

136 +because the hostnames differ. Nor would it match `foo.example.com`; Git

137 compares hostnames exactly, without considering whether two hosts are part of

138 the same domain. Likewise, a config entry for `http://example.com` would not

139 -match: git compares the protocols exactly.

139 +match: Git compares the protocols exactly.

140

141

142 CONFIGURATION OPTIONS

@@ -164,7 +164,7 @@ username::

164

165 useHttpPath::

166

167 - By default, git does not consider the "path" component of an http URL

167 + By default, Git does not consider the "path" component of an http URL

168 to be worth matching via external helpers. This means that a credential

169 stored for `https://example.com/foo.git` will also be used for

170 `https://example.com/bar.git`. If you do want to distinguish these

@@ -175,7 +175,7 @@ CUSTOM HELPERS

175 --------------

176

177 You can write your own custom helpers to interface with any system in

178 -which you keep credentials. See the documentation for git's

178 +which you keep credentials. See the documentation for Git's

179 link:technical/api-credentials.html[credentials API] for details.

180

181 GIT

Documentation/gitcvs-migration.txt

+11 -11

@@ -3,7 +3,7 @@ gitcvs-migration(7)

4 NAME

5 ----

6 -gitcvs-migration - git for CVS users

6 +gitcvs-migration - Git for CVS users

8 SYNOPSIS

9 --------

@@ -19,7 +19,7 @@ important than any other. However, you can emulate the CVS model by

19 designating a single shared repository which people can synchronize with;

20 this document explains how to do that.

22 -Some basic familiarity with git is required. Having gone through

22 +Some basic familiarity with Git is required. Having gone through

23 linkgit:gittutorial[7] and

24 linkgit:gitglossary[7] should be sufficient.

@@ -81,7 +81,7 @@ other than `master`.

81 Setting Up a Shared Repository

82 ------------------------------

84 -We assume you have already created a git repository for your project,

84 +We assume you have already created a Git repository for your project,

85 possibly created from scratch or from a tarball (see

86 linkgit:gittutorial[7]), or imported from an already existing CVS

87 repository (see the next section).

@@ -101,7 +101,7 @@ Next, give every team member read/write access to this repository. One

101 easy way to do this is to give all the team members ssh access to the

102 machine where the repository is hosted. If you don't want to give them a

103 full shell on the machine, there is a restricted shell which only allows

104 -users to do git pushes and pulls; see linkgit:git-shell[1].

104 +users to do Git pushes and pulls; see linkgit:git-shell[1].

105

106 Put all the committers in the same group, and make the repository

107 writable by that group:

@@ -125,7 +125,7 @@ of the project you are interested in and run linkgit:git-cvsimport[1]:

125 $ git cvsimport -C <destination> <module>

126 -------------------------------------------

127

128 -This puts a git archive of the named CVS module in the directory

128 +This puts a Git archive of the named CVS module in the directory

129 <destination>, which will be created if necessary.

130

131 The import checks out from CVS every revision of every file. Reportedly

@@ -133,8 +133,8 @@ cvsimport can average some twenty revisions per second, so for a

133 medium-sized project this should not take more than a couple of minutes.

134 Larger projects or remote repositories may take longer.

135

136 -The main trunk is stored in the git branch named `origin`, and additional

137 -CVS branches are stored in git branches with the same names. The most

136 +The main trunk is stored in the Git branch named `origin`, and additional

137 +CVS branches are stored in Git branches with the same names. The most

138 recent version of the main trunk is also left checked out on the `master`

139 branch, so you can start adding your own changes right away.

140

@@ -160,10 +160,10 @@ You can enforce finer grained permissions using update hooks. See

160 link:howto/update-hook-example.txt[Controlling access to branches using

161 update hooks].

162

163 -Providing CVS Access to a git Repository

163 +Providing CVS Access to a Git Repository

164 ----------------------------------------

165

166 -It is also possible to provide true CVS access to a git repository, so

166 +It is also possible to provide true CVS access to a Git repository, so

167 that developers can still use CVS; see linkgit:git-cvsserver[1] for

168 details.

169

@@ -171,8 +171,8 @@ Alternative Development Models

171 ------------------------------

172

173 CVS users are accustomed to giving a group of developers commit access to

174 -a common repository. As we've seen, this is also possible with git.

175 -However, the distributed nature of git allows other development models,

174 +a common repository. As we've seen, this is also possible with Git.

175 +However, the distributed nature of Git allows other development models,

176 and you may want to first consider whether one of them might be a better

177 fit for your project.

178

Documentation/gitdiffcore.txt

+1 -1

@@ -254,7 +254,7 @@ pattern. Filepairs that match a glob pattern on an earlier line

254 in the file are output before ones that match a later line, and

255 filepairs that do not match any glob pattern are output last.

256

257 -As an example, a typical orderfile for the core git probably

257 +As an example, a typical orderfile for the core Git probably

258 would look like this:

259

260 ------------------------------------------------

Documentation/gitglossary.txt

+1 -1

@@ -19,7 +19,7 @@ SEE ALSO

19 linkgit:gittutorial[7],

20 linkgit:gittutorial-2[7],

21 linkgit:gitcvs-migration[7],

22 -link:everyday.html[Everyday git],

22 +link:everyday.html[Everyday Git],

23 link:user-manual.html[The Git User's Manual]

25 GIT

Documentation/githooks.txt

+4 -4

@@ -3,7 +3,7 @@ githooks(5)

4 NAME

5 ----

6 -githooks - Hooks used by git

6 +githooks - Hooks used by Git

8 SYNOPSIS

9 --------

@@ -108,7 +108,7 @@ it is not suppressed by the `--no-verify` option. A non-zero exit

108 means a failure of the hook and aborts the commit. It should not

109 be used as replacement for pre-commit hook.

110

111 -The sample `prepare-commit-msg` hook that comes with git comments

111 +The sample `prepare-commit-msg` hook that comes with Git comments

112 out the `Conflicts:` part of a merge's commit message.

113

114 commit-msg

@@ -275,7 +275,7 @@ for the user.

275

276 The default 'post-receive' hook is empty, but there is

277 a sample script `post-receive-email` provided in the `contrib/hooks`

278 -directory in git distribution, which implements sending commit

278 +directory in Git distribution, which implements sending commit

279 emails.

280

281 [[post-update]]

@@ -303,7 +303,7 @@ them.

303 When enabled, the default 'post-update' hook runs

304 'git update-server-info' to keep the information used by dumb

305 transports (e.g., HTTP) up-to-date. If you are publishing

306 -a git repository that is accessible via HTTP, you should

306 +a Git repository that is accessible via HTTP, you should

307 probably enable this hook.

308

309 Both standard output and standard error output are forwarded to

Documentation/gitignore.txt

+11 -11

@@ -13,12 +13,12 @@ DESCRIPTION

13 -----------

15 A `gitignore` file specifies intentionally untracked files that

16 -git should ignore.

17 -Files already tracked by git are not affected; see the NOTES

16 +Git should ignore.

17 +Files already tracked by Git are not affected; see the NOTES

18 below for details.

20 Each line in a `gitignore` file specifies a pattern.

21 -When deciding whether to ignore a path, git normally checks

21 +When deciding whether to ignore a path, Git normally checks

22 `gitignore` patterns from multiple sources, with the following

23 order of precedence, from highest to lowest (within one level of

24 precedence, the last matching pattern decides the outcome):

@@ -53,17 +53,17 @@ be used.

53 the repository but are specific to one user's workflow) should go into

54 the `$GIT_DIR/info/exclude` file.

56 - * Patterns which a user wants git to

56 + * Patterns which a user wants Git to

57 ignore in all situations (e.g., backup or temporary files generated by

58 the user's editor of choice) generally go into a file specified by

59 `core.excludesfile` in the user's `~/.gitconfig`. Its default value is

60 $XDG_CONFIG_HOME/git/ignore. If $XDG_CONFIG_HOME is either not set or

61 empty, $HOME/.config/git/ignore is used instead.

63 -The underlying git plumbing tools, such as

63 +The underlying Git plumbing tools, such as

64 'git ls-files' and 'git read-tree', read

65 `gitignore` patterns specified by command-line options, or from

66 -files specified by command-line options. Higher-level git

66 +files specified by command-line options. Higher-level Git

67 tools, such as 'git status' and 'git add',

68 use patterns from the sources specified above.

@@ -89,15 +89,15 @@ PATTERN FORMAT

89 a match with a directory. In other words, `foo/` will match a

90 directory `foo` and paths underneath it, but will not match a

91 regular file or a symbolic link `foo` (this is consistent

92 - with the way how pathspec works in general in git).

92 + with the way how pathspec works in general in Git).

94 - - If the pattern does not contain a slash '/', git treats it as

94 + - If the pattern does not contain a slash '/', Git treats it as

95 a shell glob pattern and checks for a match against the

96 pathname relative to the location of the `.gitignore` file

97 (relative to the toplevel of the work tree if not from a

98 `.gitignore` file).

100 - - Otherwise, git treats the pattern as a shell glob suitable

100 + - Otherwise, Git treats the pattern as a shell glob suitable

101 for consumption by fnmatch(3) with the FNM_PATHNAME flag:

102 wildcards in the pattern will not match a / in the pathname.

103 For example, "Documentation/{asterisk}.html" matches

@@ -131,7 +131,7 @@ NOTES

131 -----

132

133 The purpose of gitignore files is to ensure that certain files

134 -not tracked by git remain untracked.

134 +not tracked by Git remain untracked.

135

136 To ignore uncommitted changes in a file that is already tracked,

137 use 'git update-index {litdd}assume-unchanged'.

@@ -179,7 +179,7 @@ Another example:

179 $ echo '!/vmlinux*' >arch/foo/kernel/.gitignore

180 --------------------------------------------------------------

181

182 -The second .gitignore prevents git from ignoring

182 +The second .gitignore prevents Git from ignoring

183 `arch/foo/kernel/vmlinux.lds.S`.

184

185 SEE ALSO

Documentation/gitk.txt

+4 -4

@@ -3,7 +3,7 @@ gitk(1)

4 NAME

5 ----

6 -gitk - The git repository browser

6 +gitk - The Git repository browser

8 SYNOPSIS

9 --------

@@ -18,7 +18,7 @@ the files in the trees of each revision.

19 Historically, gitk was the first repository browser. It's written in tcl/tk

20 and started off in a separate repository but was later merged into the main

21 -git repository.

21 +Git repository.

23 OPTIONS

24 -------

@@ -108,10 +108,10 @@ SEE ALSO

108

109 'gitview(1)'::

110 A repository browser written in Python using Gtk. It's based on

111 - 'bzrk(1)' and distributed in the contrib area of the git repository.

111 + 'bzrk(1)' and distributed in the contrib area of the Git repository.

112

113 'tig(1)'::

114 - A minimal repository browser and git tool output highlighter written

114 + A minimal repository browser and Git tool output highlighter written

115 in C using Ncurses.

116

117 GIT

Documentation/gitmodules.txt

+2 -2

@@ -13,7 +13,7 @@ $GIT_WORK_DIR/.gitmodules

13 DESCRIPTION

14 -----------

16 -The `.gitmodules` file, located in the top-level directory of a git

16 +The `.gitmodules` file, located in the top-level directory of a Git

17 working tree, is a text file with a syntax matching the requirements

18 of linkgit:git-config[1].

@@ -24,7 +24,7 @@ option of 'git submodule add'. Each submodule section also contains the

24 following required keys:

26 submodule.<name>.path::

27 - Defines the path, relative to the top-level directory of the git

27 + Defines the path, relative to the top-level directory of the Git

28 working tree, where the submodule is expected to be checked out.

29 The path name must not end with a `/`. All submodule paths must

30 be unique within the .gitmodules file.

Documentation/gitnamespaces.txt

+1 -1

@@ -29,7 +29,7 @@ prevent duplication between new objects added to the repositories

29 without ongoing maintenance, while namespaces do.

31 To specify a namespace, set the `GIT_NAMESPACE` environment variable to

32 -the namespace. For each ref namespace, git stores the corresponding

32 +the namespace. For each ref namespace, Git stores the corresponding

33 refs in a directory under `refs/namespaces/`. For example,

34 `GIT_NAMESPACE=foo` will store refs under `refs/namespaces/foo/`. You

35 can also specify namespaces via the `--namespace` option to

Documentation/gitrepository-layout.txt

+5 -5

@@ -12,12 +12,12 @@ $GIT_DIR/*

12 DESCRIPTION

13 -----------

15 -You may find these things in your git repository (`.git`

15 +You may find these things in your Git repository (`.git`

16 directory for a repository associated with your working tree, or

17 `<project>.git` directory for a public 'bare' repository. It is

18 also possible to have a working tree where `.git` is a plain

19 ASCII file containing `gitdir: <path>`, i.e. the path to the

20 -real git repository).

20 +real Git repository).

22 objects::

23 Object store associated with this repository. Usually

@@ -108,7 +108,7 @@ HEAD::

108 A symref (see glossary) to the `refs/heads/` namespace

109 describing the currently active branch. It does not mean

110 much if the repository is not associated with any working tree

111 - (i.e. a 'bare' repository), but a valid git repository

111 + (i.e. a 'bare' repository), but a valid Git repository

112 *must* have the HEAD file; some porcelains may use it to

113 guess the designated "default" branch of the repository

114 (usually 'master'). It is legal if the named branch

@@ -131,7 +131,7 @@ branches::

131 and not likely to be found in modern repositories.

132

133 hooks::

134 - Hooks are customization scripts used by various git

134 + Hooks are customization scripts used by various Git

135 commands. A handful of sample hooks are installed when

136 'git init' is run, but all of them are disabled by

137 default. To enable, the `.sample` suffix has to be

@@ -169,7 +169,7 @@ info/exclude::

169 This file, by convention among Porcelains, stores the

170 exclude pattern list. `.gitignore` is the per-directory

171 ignore file. 'git status', 'git add', 'git rm' and

172 - 'git clean' look at it but the core git commands do not look

172 + 'git clean' look at it but the core Git commands do not look

173 at it. See also: linkgit:gitignore[5].

174

175 remotes::

Documentation/gitrevisions.txt

+1 -1

@@ -3,7 +3,7 @@ gitrevisions(7)

4 NAME

5 ----

6 -gitrevisions - specifying revisions and ranges for git

6 +gitrevisions - specifying revisions and ranges for Git

8 SYNOPSIS

9 --------

Documentation/gittutorial-2.txt

+19 -19

@@ -3,7 +3,7 @@ gittutorial-2(7)

4 NAME

5 ----

6 -gittutorial-2 - A tutorial introduction to git: part two

6 +gittutorial-2 - A tutorial introduction to Git: part two

8 SYNOPSIS

9 --------

@@ -16,11 +16,11 @@ DESCRIPTION

16 You should work through linkgit:gittutorial[7] before reading this tutorial.

18 The goal of this tutorial is to introduce two fundamental pieces of

19 -git's architecture--the object database and the index file--and to

19 +Git's architecture--the object database and the index file--and to

20 provide the reader with everything necessary to understand the rest

21 -of the git documentation.

21 +of the Git documentation.

23 -The git object database

23 +The Git object database

24 -----------------------

26 Let's start a new project and create a small amount of history:

@@ -42,14 +42,14 @@ $ git commit -a -m "add emphasis"

42 1 file changed, 1 insertion(+), 1 deletion(-)

43 ------------------------------------------------

45 -What are the 7 digits of hex that git responded to the commit with?

45 +What are the 7 digits of hex that Git responded to the commit with?

47 We saw in part one of the tutorial that commits have names like this.

48 -It turns out that every object in the git history is stored under

48 +It turns out that every object in the Git history is stored under

49 a 40-digit hex name. That name is the SHA1 hash of the object's

50 -contents; among other things, this ensures that git will never store

50 +contents; among other things, this ensures that Git will never store

51 the same data twice (since identical data is given an identical SHA1

52 -name), and that the contents of a git object will never change (since

52 +name), and that the contents of a Git object will never change (since

53 that would change the object's name as well). The 7 char hex strings

54 here are simply the abbreviation of such 40 character long strings.

55 Abbreviations can be used everywhere where the 40 character strings

@@ -60,7 +60,7 @@ following the example above generates a different SHA1 hash than

60 the one shown above because the commit object records the time when

61 it was created and the name of the person performing the commit.

63 -We can ask git about this particular object with the `cat-file`

63 +We can ask Git about this particular object with the `cat-file`

64 command. Don't copy the 40 hex digits from this example but use those

65 from your own version. Note that you can shorten it to only a few

66 characters to save yourself typing all 40 hex digits:

@@ -102,11 +102,11 @@ $ git cat-file blob 3b18e512

102 hello world

103 ------------------------------------------------

104

105 -Note that this is the old file data; so the object that git named in

105 +Note that this is the old file data; so the object that Git named in

106 its response to the initial tree was a tree with a snapshot of the

107 directory state that was recorded by the first commit.

108

109 -All of these objects are stored under their SHA1 names inside the git

109 +All of these objects are stored under their SHA1 names inside the Git

110 directory:

111

112 ------------------------------------------------

@@ -191,7 +191,7 @@ Besides blobs, trees, and commits, the only remaining type of object

191 is a "tag", which we won't discuss here; refer to linkgit:git-tag[1]

192 for details.

193

194 -So now we know how git uses the object database to represent a

194 +So now we know how Git uses the object database to represent a

195 project's history:

196

197 * "commit" objects refer to "tree" objects representing the

@@ -403,21 +403,21 @@ What next?

403

404 At this point you should know everything necessary to read the man

405 pages for any of the git commands; one good place to start would be

406 -with the commands mentioned in link:everyday.html[Everyday git]. You

406 +with the commands mentioned in link:everyday.html[Everyday Git]. You

407 should be able to find any unknown jargon in linkgit:gitglossary[7].

408

409 The link:user-manual.html[Git User's Manual] provides a more

410 -comprehensive introduction to git.

410 +comprehensive introduction to Git.

411

412 linkgit:gitcvs-migration[7] explains how to

413 -import a CVS repository into git, and shows how to use git in a

413 +import a CVS repository into Git, and shows how to use Git in a

414 CVS-like way.

415

416 -For some interesting examples of git use, see the

416 +For some interesting examples of Git use, see the

417 link:howto-index.html[howtos].

418

419 -For git developers, linkgit:gitcore-tutorial[7] goes

420 -into detail on the lower-level git mechanisms involved in, for

419 +For Git developers, linkgit:gitcore-tutorial[7] goes

420 +into detail on the lower-level Git mechanisms involved in, for

421 example, creating a new commit.

422

423 SEE ALSO

@@ -427,7 +427,7 @@ linkgit:gitcvs-migration[7],

427 linkgit:gitcore-tutorial[7],

428 linkgit:gitglossary[7],

429 linkgit:git-help[1],

430 -link:everyday.html[Everyday git],

430 +link:everyday.html[Everyday Git],

431 link:user-manual.html[The Git User's Manual]

432

433 GIT

Documentation/gittutorial.txt

+22 -22

@@ -3,7 +3,7 @@ gittutorial(7)

4 NAME

5 ----

6 -gittutorial - A tutorial introduction to git (for version 1.5.1 or newer)

6 +gittutorial - A tutorial introduction to Git (for version 1.5.1 or newer)

8 SYNOPSIS

9 --------

@@ -13,10 +13,10 @@ git *

13 DESCRIPTION

14 -----------

16 -This tutorial explains how to import a new project into git, make

16 +This tutorial explains how to import a new project into Git, make

17 changes to it, and share changes with other developers.

19 -If you are instead primarily interested in using git to fetch a project,

19 +If you are instead primarily interested in using Git to fetch a project,

20 for example, to test the latest version, you may prefer to start with

21 the first two chapters of link:user-manual.html[The Git User's Manual].

@@ -36,7 +36,7 @@ $ git help log

36 With the latter, you can use the manual viewer of your choice; see

37 linkgit:git-help[1] for more information.

39 -It is a good idea to introduce yourself to git with your name and

39 +It is a good idea to introduce yourself to Git with your name and

40 public email address before doing any operation. The easiest

41 way to do so is:

@@ -50,7 +50,7 @@ Importing a new project

50 -----------------------

52 Assume you have a tarball project.tar.gz with your initial work. You

53 -can place it under git revision control as follows.

53 +can place it under Git revision control as follows.

55 ------------------------------------------------

56 $ tar xzf project.tar.gz

@@ -67,14 +67,14 @@ Initialized empty Git repository in .git/

67 You've now initialized the working directory--you may notice a new

68 directory created, named ".git".

70 -Next, tell git to take a snapshot of the contents of all files under the

70 +Next, tell Git to take a snapshot of the contents of all files under the

71 current directory (note the '.'), with 'git add':

73 ------------------------------------------------

74 $ git add .

75 ------------------------------------------------

77 -This snapshot is now stored in a temporary staging area which git calls

77 +This snapshot is now stored in a temporary staging area which Git calls

78 the "index". You can permanently store the contents of the index in the

79 repository with 'git commit':

@@ -83,7 +83,7 @@ $ git commit

83 ------------------------------------------------

85 This will prompt you for a commit message. You've now stored the first

86 -version of your project in git.

86 +version of your project in Git.

88 Making changes

89 --------------

@@ -141,7 +141,7 @@ begin the commit message with a single short (less than 50 character)

141 line summarizing the change, followed by a blank line and then a more

142 thorough description. The text up to the first blank line in a commit

143 message is treated as the commit title, and that title is used

144 -throughout git. For example, linkgit:git-format-patch[1] turns a

144 +throughout Git. For example, linkgit:git-format-patch[1] turns a

145 commit into email, and it uses the title on the Subject line and the

146 rest of the commit in the body.

147

@@ -180,7 +180,7 @@ $ git log --stat --summary

180 Managing branches

181 -----------------

182

183 -A single git repository can maintain multiple branches of

183 +A single Git repository can maintain multiple branches of

184 development. To create a new branch named "experimental", use

185

186 ------------------------------------------------

@@ -276,10 +276,10 @@ $ git branch -D crazy-idea

276 Branches are cheap and easy, so this is a good way to try something

277 out.

278

279 -Using git for collaboration

279 +Using Git for collaboration

280 ---------------------------

281

282 -Suppose that Alice has started a new project with a git repository in

282 +Suppose that Alice has started a new project with a Git repository in

283 /home/alice/project, and that Bob, who has a home directory on the

284 same machine, wants to contribute.

285

@@ -320,7 +320,7 @@ Note that in general, Alice would want her local changes committed before

320 initiating this "pull". If Bob's work conflicts with what Alice did since

321 their histories forked, Alice will use her working tree and the index to

322 resolve conflicts, and existing local changes will interfere with the

323 -conflict resolution process (git will still perform the fetch but will

323 +conflict resolution process (Git will still perform the fetch but will

324 refuse to merge --- Alice will have to get rid of her local changes in

325 some way and pull again when this happens).

326

@@ -422,7 +422,7 @@ bob$ git pull

422 -------------------------------------

423

424 Note that he doesn't need to give the path to Alice's repository;

425 -when Bob cloned Alice's repository, git stored the location of her

425 +when Bob cloned Alice's repository, Git stored the location of her

426 repository in the repository configuration, and that location is

427 used for pulls:

428

@@ -450,7 +450,7 @@ perform clones and pulls using the ssh protocol:

450 bob$ git clone alice.org:/home/alice/project myrepo

451 -------------------------------------

452

453 -Alternatively, git has a native protocol, or can use rsync or http;

453 +Alternatively, Git has a native protocol, or can use rsync or http;

454 see linkgit:git-pull[1] for details.

455

456 Git can also be used in a CVS-like mode, with a central repository

@@ -518,7 +518,7 @@ share this name with other people (for example, to identify a release

518 version), you should create a "tag" object, and perhaps sign it; see

519 linkgit:git-tag[1] for details.

520

521 -Any git command that needs to know a commit can take any of these

521 +Any Git command that needs to know a commit can take any of these

522 names. For example:

523

524 -------------------------------------

@@ -554,9 +554,9 @@ files it manages in your current directory. So

554 $ git grep "hello"

555 -------------------------------------

556

557 -is a quick way to search just the files that are tracked by git.

557 +is a quick way to search just the files that are tracked by Git.

558

559 -Many git commands also take sets of commits, which can be specified

559 +Many Git commands also take sets of commits, which can be specified

560 in a number of ways. Here are some examples with 'git log':

561

562 -------------------------------------

@@ -592,7 +592,7 @@ then merged back together, the order in which 'git log' presents

592 those commits is meaningless.

593

594 Most projects with multiple contributors (such as the Linux kernel,

595 -or git itself) have frequent merges, and 'gitk' does a better job of

595 +or Git itself) have frequent merges, and 'gitk' does a better job of

596 visualizing their history. For example,

597

598 -------------------------------------

@@ -623,7 +623,7 @@ Next Steps

623

624 This tutorial should be enough to perform basic distributed revision

625 control for your projects. However, to fully understand the depth

626 -and power of git you need to understand two simple ideas on which it

626 +and power of Git you need to understand two simple ideas on which it

627 is based:

628

629 * The object database is the rather elegant system used to

@@ -636,7 +636,7 @@ is based:

636

637 Part two of this tutorial explains the object

638 database, the index file, and a few other odds and ends that you'll

639 -need to make the most of git. You can find it at linkgit:gittutorial-2[7].

639 +need to make the most of Git. You can find it at linkgit:gittutorial-2[7].

640

641 If you don't want to continue with that right away, a few other

642 digressions that may be interesting at this point are:

@@ -668,7 +668,7 @@ linkgit:gitcore-tutorial[7],

668 linkgit:gitglossary[7],

669 linkgit:git-help[1],

670 linkgit:gitworkflows[7],

671 -link:everyday.html[Everyday git],

671 +link:everyday.html[Everyday Git],

672 link:user-manual.html[The Git User's Manual]

673

674 GIT

Documentation/gitweb.conf.txt

+16 -16

@@ -3,7 +3,7 @@ gitweb.conf(5)

4 NAME

5 ----

6 -gitweb.conf - Gitweb (git web interface) configuration file

6 +gitweb.conf - Gitweb (Git web interface) configuration file

8 SYNOPSIS

9 --------

@@ -79,7 +79,7 @@ stops declaring it.

79 You can include other configuration file using read_config_file()

80 subroutine. For example, one might want to put gitweb configuration

81 related to access control for viewing repositories via Gitolite (one

82 -of git repository management tools) in a separate file, e.g. in

82 +of Git repository management tools) in a separate file, e.g. in

83 '/etc/gitweb-gitolite.conf'. To include it, put

85 --------------------------------------------------

@@ -111,7 +111,7 @@ and installing gitweb.

111 Location of repositories

112 ~~~~~~~~~~~~~~~~~~~~~~~~

113 The configuration variables described below control how gitweb finds

114 -git repositories, and how repositories are displayed and accessed.

114 +Git repositories, and how repositories are displayed and accessed.

115

116 See also "Repositories" and later subsections in linkgit:gitweb[1] manpage.

117

@@ -159,7 +159,7 @@ will fall back to scanning the `$projectroot` directory for repositories.

159

160 $project_maxdepth::

161 If `$projects_list` variable is unset, gitweb will recursively

162 - scan filesystem for git repositories. The `$project_maxdepth`

162 + scan filesystem for Git repositories. The `$project_maxdepth`

163 is used to limit traversing depth, relative to `$projectroot`

164 (starting point); it means that directories which are further

165 from `$projectroot` than `$project_maxdepth` will be skipped.

@@ -200,7 +200,7 @@ our $export_ok = "git-daemon-export-ok";

200 +

201 If not set (default), it means that this feature is disabled.

202 +

203 -See also more involved example in "Controlling access to git repositories"

203 +See also more involved example in "Controlling access to Git repositories"

204 subsection on linkgit:gitweb[1] manpage.

205

206 $strict_export::

@@ -222,18 +222,18 @@ The values of these variables are paths on the filesystem.

222

223 $GIT::

224 Core git executable to use. By default set to `$GIT_BINDIR/git`, which

225 - in turn is by default set to `$(bindir)/git`. If you use git installed

225 + in turn is by default set to `$(bindir)/git`. If you use Git installed

226 from a binary package, you should usually set this to "/usr/bin/git".

227 This can just be "git" if your web server has a sensible PATH; from

228 security point of view it is better to use absolute path to git binary.

229 - If you have multiple git versions installed it can be used to choose

229 + If you have multiple Git versions installed it can be used to choose

230 which one to use. Must be (correctly) set for gitweb to be able to

231 work.

232

233 $mimetypes_file::

234 File to use for (filename extension based) guessing of MIME types before

235 trying '/etc/mime.types'. *NOTE* that this path, if relative, is taken

236 - as relative to the current git repository, not to CGI script. If unset,

236 + as relative to the current Git repository, not to CGI script. If unset,

237 only '/etc/mime.types' is used (if present on filesystem). If no mimetypes

238 file is found, mimetype guessing based on extension of file is disabled.

239 Unset by default.

@@ -343,8 +343,8 @@ $logo_url::

343 $logo_label::

344 URI and label (title) for the Git logo link (or your site logo,

345 if you chose to use different logo image). By default, these both

346 - refer to git homepage, http://git-scm.com[]; in the past, they pointed

347 - to git documentation at http://www.kernel.org[].

346 + refer to Git homepage, http://git-scm.com[]; in the past, they pointed

347 + to Git documentation at http://www.kernel.org[].

348

349

350 Changing gitweb's look

@@ -436,7 +436,7 @@ $fallback_encoding::

436 detection.

437 +

438 *Note* that rename and especially copy detection can be quite

439 -CPU-intensive. Note also that non git tools can have problems with

439 +CPU-intensive. Note also that non Git tools can have problems with

440 patches generated with options mentioned above, especially when they

441 involve file copies (\'-C') or criss-cross renames (\'-B').

442

@@ -451,7 +451,7 @@ looks does contain variables configuring administrative side of gitweb

451 affects how "summary" pages look like, or load limiting).

452

453 @git_base_url_list::

454 - List of git base URLs. These URLs are used to generate URLs

454 + List of Git base URLs. These URLs are used to generate URLs

455 describing from where to fetch a project, which are shown on

456 project summary page. The full fetch URL is "`$git_base_url/$project`",

457 for each element of this list. You can set up multiple base URLs

@@ -616,7 +616,7 @@ override::

616 (or enabled/disabled) on a per-repository basis.

617 +

618 Usually given "<feature>" is configurable via the `gitweb.<feature>`

619 -config variable in the per-repository git configuration file.

619 +config variable in the per-repository Git configuration file.

620 +

621 *Note* that no feature is overriddable by default.

622

@@ -782,7 +782,7 @@ filesystem (i.e. "$projectroot/$project"), `%h` to the current hash

782 (\'hb' gitweb parameter); `%%` expands to \'%'.

783 +

784 For example, at the time this page was written, the http://repo.or.cz[]

785 -git hosting site set it to the following to enable graphical log

785 +Git hosting site set it to the following to enable graphical log

786 (using the third party tool *git-browser*):

787 +

788 ----------------------------------------------------------------------

@@ -796,10 +796,10 @@ This adds a link titled "graphiclog" after the "summary" link, leading to

796 Project specific override is not supported.

797

798 timed::

799 - Enable displaying how much time and how many git commands it took to

799 + Enable displaying how much time and how many Git commands it took to

800 generate and display each page in the page footer (at the bottom of

801 page). For example the footer might contain: "This page took 6.53325

802 - seconds and 13 git commands to generate." Disabled by default.

802 + seconds and 13 Git commands to generate." Disabled by default.

803 +

804 Project specific override is not supported.

805

Documentation/gitweb.txt

+10 -10

@@ -7,14 +7,14 @@ gitweb - Git web interface (web frontend to Git repositories)

8 SYNOPSIS

9 --------

10 -To get started with gitweb, run linkgit:git-instaweb[1] from a git repository.

10 +To get started with gitweb, run linkgit:git-instaweb[1] from a Git repository.

11 This would configure and start your web server, and run web browser pointing to

12 gitweb.

15 DESCRIPTION

16 -----------

17 -Gitweb provides a web interface to git repositories. Its features include:

17 +Gitweb provides a web interface to Git repositories. Its features include:

19 * Viewing multiple Git repositories with common root.

20 * Browsing every revision of the repository.

@@ -54,9 +54,9 @@ our $projectroot = '/path/to/parent/directory';

54 The default value for `$projectroot` is '/pub/git'. You can change it during

55 building gitweb via `GITWEB_PROJECTROOT` build configuration variable.

57 -By default all git repositories under `$projectroot` are visible and available

57 +By default all Git repositories under `$projectroot` are visible and available

58 to gitweb. The list of projects is generated by default by scanning the

59 -`$projectroot` directory for git repositories (for object databases to be

59 +`$projectroot` directory for Git repositories (for object databases to be

60 more exact; gitweb is not interested in a working area, and is best suited

61 to showing "bare" repositories).

@@ -111,7 +111,7 @@ foo/bar.git O+W+Ner+<owner@example.org>

111

112

113 By default this file controls only which projects are *visible* on projects

114 -list page (note that entries that do not point to correctly recognized git

114 +list page (note that entries that do not point to correctly recognized Git

115 repositories won't be displayed by gitweb). Even if a project is not

116 visible on projects list page, you can view it nevertheless by hand-crafting

117 a gitweb URL. By setting `$strict_export` configuration variable (see

@@ -151,9 +151,9 @@ as projects list file, which means that you can set `$projects_list` to its

151 filename.

152

153

154 -Controlling access to git repositories

154 +Controlling access to Git repositories

155 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

156 -By default all git repositories under `$projectroot` are visible and

156 +By default all Git repositories under `$projectroot` are visible and

157 available to gitweb. You can however configure how gitweb controls access

158 to repositories.

159

@@ -206,7 +206,7 @@ $export_auth_hook = sub {

206 Per-repository gitweb configuration

207 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

208 You can configure individual repositories shown in gitweb by creating file

209 -in the 'GIT_DIR' of git repository, or by setting some repo configuration

209 +in the 'GIT_DIR' of Git repository, or by setting some repo configuration

210 variable (in 'GIT_DIR/config', see linkgit:git-config[1]).

211

212 You can use the following files in repository:

@@ -584,7 +584,7 @@ $projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/pub/git";

584 referenced by `$per_request_config`;

585

586 These configurations enable two things. First, each unix user (`<user>`) of

587 -the server will be able to browse through gitweb git repositories found in

587 +the server will be able to browse through gitweb Git repositories found in

588 '~/public_git/' with the following url:

589

590 http://git.example.org/~<user>/

@@ -673,7 +673,7 @@ The additional AliasMatch makes it so that

673

674 http://git.example.com/project.git

675

676 -will give raw access to the project's git dir (so that the project can be

676 +will give raw access to the project's Git dir (so that the project can be

677 cloned), while

678

679 http://git.example.com/project

Documentation/gitworkflows.txt

+2 -2

@@ -3,7 +3,7 @@ gitworkflows(7)

4 NAME

5 ----

6 -gitworkflows - An overview of recommended workflows with git

6 +gitworkflows - An overview of recommended workflows with Git

8 SYNOPSIS

9 --------

@@ -245,7 +245,7 @@ tag to the tip of 'master' indicating the release version:

245 `git tag -s -m "Git X.Y.Z" vX.Y.Z master`

246 =====================================

247

248 -You need to push the new tag to a public git server (see

248 +You need to push the new tag to a public Git server (see

249 "DISTRIBUTED WORKFLOWS" below). This makes the tag available to

250 others tracking your project. The push could also trigger a

251 post-update hook to perform release-related items such as building

Documentation/glossary-content.txt

+28 -28

@@ -7,7 +7,7 @@

7 A bare repository is normally an appropriately

8 named <<def_directory,directory>> with a `.git` suffix that does not

9 have a locally checked-out copy of any of the files under

10 - revision control. That is, all of the `git`

10 + revision control. That is, all of the Git

11 administrative and control files that would normally be present in the

12 hidden `.git` sub-directory are directly present in the

13 `repository.git` directory instead,

@@ -22,7 +22,7 @@

22 <<def_commit,commit>> on a branch is referred to as the tip of

23 that branch. The tip of the branch is referenced by a branch

24 <<def_head,head>>, which moves forward as additional development

25 - is done on the branch. A single git

25 + is done on the branch. A single Git

26 <<def_repository,repository>> can track an arbitrary number of

27 branches, but your <<def_working_tree,working tree>> is

28 associated with just one of them (the "current" or "checked out"

@@ -37,9 +37,9 @@

37 <<def_commit,commit>> could be one of its <<def_parent,parents>>).

39 [[def_changeset]]changeset::

40 - BitKeeper/cvsps speak for "<<def_commit,commit>>". Since git does not

40 + BitKeeper/cvsps speak for "<<def_commit,commit>>". Since Git does not

41 store changes, but states, it really does not make sense to use the term

42 - "changesets" with git.

42 + "changesets" with Git.

44 [[def_checkout]]checkout::

45 The action of updating all or part of the

@@ -64,14 +64,14 @@

65 [[def_commit]]commit::

66 As a noun: A single point in the

67 - git history; the entire history of a project is represented as a

67 + Git history; the entire history of a project is represented as a

68 set of interrelated commits. The word "commit" is often

69 - used by git in the same places other revision control systems

69 + used by Git in the same places other revision control systems

70 use the words "revision" or "version". Also used as a short

71 hand for <<def_commit_object,commit object>>.

72 +

73 As a verb: The action of storing a new snapshot of the project's

74 -state in the git history, by creating a new commit representing the current

74 +state in the Git history, by creating a new commit representing the current

75 state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>>

76 to point at the new commit.

@@ -82,8 +82,8 @@ to point at the new commit.

82 to the top <<def_directory,directory>> of the stored

83 revision.

85 -[[def_core_git]]core git::

86 - Fundamental data structures and utilities of git. Exposes only limited

85 +[[def_core_git]]core Git::

86 + Fundamental data structures and utilities of Git. Exposes only limited

87 source code management tools.

89 [[def_DAG]]DAG::

@@ -100,7 +100,7 @@ to point at the new commit.

100

101 [[def_detached_HEAD]]detached HEAD::

102 Normally the <<def_HEAD,HEAD>> stores the name of a

103 - <<def_branch,branch>>. However, git also allows you to <<def_checkout,check out>>

103 + <<def_branch,branch>>. However, Git also allows you to <<def_checkout,check out>>

104 an arbitrary <<def_commit,commit>> that isn't necessarily the tip of any

105 particular branch. In this case HEAD is said to be "detached".

106

@@ -142,22 +142,22 @@ to point at the new commit.

142 and to get them, too. See also linkgit:git-fetch[1].

143

144 [[def_file_system]]file system::

145 - Linus Torvalds originally designed git to be a user space file system,

145 + Linus Torvalds originally designed Git to be a user space file system,

146 i.e. the infrastructure to hold files and directories. That ensured the

147 - efficiency and speed of git.

147 + efficiency and speed of Git.

148

149 -[[def_git_archive]]git archive::

149 +[[def_git_archive]]Git archive::

150 Synonym for <<def_repository,repository>> (for arch people).

151

152 [[def_grafts]]grafts::

153 Grafts enables two otherwise different lines of development to be joined

154 together by recording fake ancestry information for commits. This way

155 - you can make git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has

155 + you can make Git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has

156 is different from what was recorded when the commit was

157 created. Configured via the `.git/info/grafts` file.

158

159 [[def_hash]]hash::

160 - In git's context, synonym to <<def_object_name,object name>>.

160 + In Git's context, synonym to <<def_object_name,object name>>.

161

162 [[def_head]]head::

163 A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a

@@ -177,14 +177,14 @@ to point at the new commit.

177 A synonym for <<def_head,head>>.

178

179 [[def_hook]]hook::

180 - During the normal execution of several git commands, call-outs are made

180 + During the normal execution of several Git commands, call-outs are made

181 to optional scripts that allow a developer to add functionality or

182 checking. Typically, the hooks allow for a command to be pre-verified

183 and potentially aborted, and allow for a post-notification after the

184 operation is done. The hook scripts are found in the

185 `$GIT_DIR/hooks/` directory, and are enabled by simply

186 removing the `.sample` suffix from the filename. In earlier versions

187 - of git you had to make them executable.

187 + of Git you had to make them executable.

188

189 [[def_index]]index::

190 A collection of files with stat information, whose contents are stored

@@ -201,7 +201,7 @@ to point at the new commit.

201

202 [[def_master]]master::

203 The default development <<def_branch,branch>>. Whenever you

204 - create a git <<def_repository,repository>>, a branch named

204 + create a Git <<def_repository,repository>>, a branch named

205 "master" is created, and becomes the active branch. In most

206 cases, this contains the local development, though that is

207 purely by convention and is not required.

@@ -228,7 +228,7 @@ This commit is referred to as a "merge commit", or sometimes just a

228 "merge".

229

230 [[def_object]]object::

231 - The unit of storage in git. It is uniquely identified by the

231 + The unit of storage in Git. It is uniquely identified by the

232 <<def_SHA1,SHA1>> of its contents. Consequently, an

233 object can not be changed.

234

@@ -323,7 +323,7 @@ top `/`;;

323 +

324 Currently only the slash `/` is recognized as the "magic signature",

325 but it is envisioned that we will support more types of magic in later

326 -versions of git.

326 +versions of Git.

327 +

328 A pathspec with only a colon means "there is no pathspec". This form

329 should not be combined with other pathspec.

@@ -341,12 +341,12 @@ should not be combined with other pathspec.

341 particular line of text. See linkgit:git-diff[1].

342

343 [[def_plumbing]]plumbing::

344 - Cute name for <<def_core_git,core git>>.

344 + Cute name for <<def_core_git,core Git>>.

345

346 [[def_porcelain]]porcelain::

347 Cute name for programs and program suites depending on

348 - <<def_core_git,core git>>, presenting a high level access to

349 - core git. Porcelains expose more of a <<def_SCM,SCM>>

348 + <<def_core_git,core Git>>, presenting a high level access to

349 + core Git. Porcelains expose more of a <<def_SCM,SCM>>

350 interface than the <<def_plumbing,plumbing>>.

351

352 [[def_pull]]pull::

@@ -406,7 +406,7 @@ should not be combined with other pathspec.

406 linkgit:git-push[1].

407

408 [[def_remote_tracking_branch]]remote-tracking branch::

409 - A regular git <<def_branch,branch>> that is used to follow changes from

409 + A regular Git <<def_branch,branch>> that is used to follow changes from

410 another <<def_repository,repository>>. A remote-tracking

411 branch should not contain direct modifications or have local commits

412 made to it. A remote-tracking branch can usually be

@@ -443,7 +443,7 @@ should not be combined with other pathspec.

443 [[def_shallow_repository]]shallow repository::

444 A shallow <<def_repository,repository>> has an incomplete

445 history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other

446 - words, git is told to pretend that these commits do not have the

446 + words, Git is told to pretend that these commits do not have the

447 parents, even though they are recorded in the <<def_commit_object,commit

448 object>>). This is sometimes useful when you are interested only in the

449 recent history of a project even though the real history recorded in the

@@ -464,9 +464,9 @@ should not be combined with other pathspec.

464 object of an arbitrary type (typically a tag points to either a

465 <<def_tag_object,tag>> or a <<def_commit_object,commit object>>).

466 In contrast to a <<def_head,head>>, a tag is not updated by

467 - the `commit` command. A git tag has nothing to do with a Lisp

467 + the `commit` command. A Git tag has nothing to do with a Lisp

468 tag (which would be called an <<def_object_type,object type>>

469 - in git's context). A tag is most typically used to mark a particular

469 + in Git's context). A tag is most typically used to mark a particular

470 point in the commit ancestry <<def_chain,chain>>.

471

472 [[def_tag_object]]tag object::

@@ -476,7 +476,7 @@ should not be combined with other pathspec.

476 signature, in which case it is called a "signed tag object".

477

478 [[def_topic_branch]]topic branch::

479 - A regular git <<def_branch,branch>> that is used by a developer to

479 + A regular Git <<def_branch,branch>> that is used by a developer to

480 identify a conceptual line of development. Since branches are very easy

481 and inexpensive, it is often desirable to have several small branches

482 that each contain very well defined concepts or small incremental yet

Documentation/howto-index.sh

+1 -1

@@ -5,7 +5,7 @@ Git Howto Index

5 ===============

7 Here is a collection of mailing list postings made by various

8 -people describing how they use git in their workflow.

8 +people describing how they use Git in their workflow.

10 EOF

Documentation/howto/maintain-git.txt

+3 -3

@@ -1,7 +1,7 @@

1 From: Junio C Hamano <gitster@pobox.com>

2 Date: Wed, 21 Nov 2007 16:32:55 -0800

3 Subject: Addendum to "MaintNotes"

4 -Abstract: Imagine that git development is racing along as usual, when our friendly

4 +Abstract: Imagine that Git development is racing along as usual, when our friendly

5 neighborhood maintainer is struck down by a wayward bus. Out of the

6 hordes of suckers (loyal developers), you have been tricked (chosen) to

7 step up as the new maintainer. This howto will show you "how to" do it.

@@ -10,7 +10,7 @@ Content-type: text/asciidoc

10 How to maintain Git

11 ===================

13 -The maintainer's git time is spent on three activities.

13 +The maintainer's Git time is spent on three activities.

15 - Communication (60%)

@@ -77,7 +77,7 @@ The policy.

77 are found before new topics are merged to 'master'.

80 -A typical git day for the maintainer implements the above policy

80 +A typical Git day for the maintainer implements the above policy

81 by doing the following:

83 - Scan mailing list and #git channel log. Respond with review

Documentation/howto/new-command.txt

+10 -10

@@ -1,25 +1,25 @@

1 From: Eric S. Raymond <esr@thyrsus.com>

2 Abstract: This is how-to documentation for people who want to add extension

3 - commands to git. It should be read alongside api-builtin.txt.

3 + commands to Git. It should be read alongside api-builtin.txt.

4 Content-type: text/asciidoc

6 How to integrate new subcommands

7 ================================

9 This is how-to documentation for people who want to add extension

10 -commands to git. It should be read alongside api-builtin.txt.

10 +commands to Git. It should be read alongside api-builtin.txt.

12 Runtime environment

13 -------------------

15 -git subcommands are standalone executables that live in the git exec

15 +Git subcommands are standalone executables that live in the Git exec

16 path, normally /usr/lib/git-core. The git executable itself is a

17 thin wrapper that knows where the subcommands live, and runs them by

18 passing command-line arguments to them.

20 -(If "git foo" is not found in the git exec path, the wrapper

20 +(If "git foo" is not found in the Git exec path, the wrapper

21 will look in the rest of your $PATH for it. Thus, it's possible

22 -to write local git extensions that don't live in system space.)

22 +to write local Git extensions that don't live in system space.)

24 Implementation languages

25 ------------------------

@@ -30,13 +30,13 @@ Perl.

30 While we strongly encourage coding in portable C for portability,

31 these specific scripting languages are also acceptable. We won't

32 accept more without a very strong technical case, as we don't want

33 -to broaden the git suite's required dependencies. Import utilities,

33 +to broaden the Git suite's required dependencies. Import utilities,

34 surgical tools, remote helpers and other code at the edges of the

35 -git suite are more lenient and we allow Python (and even Tcl/tk),

35 +Git suite are more lenient and we allow Python (and even Tcl/tk),

36 but they should not be used for core functions.

38 This may change in the future. Especially Python is not allowed in

39 -core because we need better Python integration in the git Windows

39 +core because we need better Python integration in the Git Windows

40 installer before we can be confident people in that environment

41 won't experience an unacceptably large loss of capability.

@@ -54,7 +54,7 @@ functions available to built-in commands written in C.

54 What every extension command needs

55 ----------------------------------

57 -You must have a man page, written in asciidoc (this is what git help

57 +You must have a man page, written in asciidoc (this is what Git help

58 followed by your subcommand name will display). Be aware that there is

59 a local asciidoc configuration and macros which you should use. It's

60 often helpful to start by cloning an existing page and replacing the

@@ -74,7 +74,7 @@ Integrating a command

74 ---------------------

76 Here are the things you need to do when you want to merge a new

77 -subcommand into the git tree.

77 +subcommand into the Git tree.

79 1. Don't forget to sign off your patch!

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

+4 -4

@@ -3,7 +3,7 @@ Message-ID: <7vy86o6usx.fsf@assigned-by-dhcp.cox.net>

3 From: Junio C Hamano <gitster@pobox.com>

4 Date: Fri, 26 Aug 2005 18:19:10 -0700

5 Abstract: In this how-to article, JC talks about how he

6 - uses the post-update hook to automate git documentation page

6 + uses the post-update hook to automate Git documentation page

7 shown at http://www.kernel.org/pub/software/scm/git/docs/.

8 Content-type: text/asciidoc

@@ -15,11 +15,11 @@ are built from Documentation/ directory of the git.git project

15 and needed to be kept up-to-date. The www.kernel.org/ servers

16 are mirrored and I was told that the origin of the mirror is on

17 the machine $some.kernel.org, on which I was given an account

18 -when I took over git maintainership from Linus.

18 +when I took over Git maintainership from Linus.

20 The directories relevant to this how-to are these two:

22 - /pub/scm/git/git.git/ The public git repository.

22 + /pub/scm/git/git.git/ The public Git repository.

23 /pub/software/scm/git/docs/ The HTML documentation page.

25 So I made a repository to generate the documentation under my

@@ -46,7 +46,7 @@ script:

46 EOF

48 Initially I used to run this by hand whenever I push into the

49 -public git repository. Then I did a cron job that ran twice a

49 +public Git repository. Then I did a cron job that ran twice a

50 day. The current round uses the post-update hook mechanism,

51 like this:

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

+2 -2

@@ -20,7 +20,7 @@ itself doesn't actually tell you anything, in order to fix a corrupt

20 object you basically have to find the "original source" for it.

22 The easiest way to do that is almost always to have backups, and find the

23 -same object somewhere else. Backups really are a good idea, and git makes

23 +same object somewhere else. Backups really are a good idea, and Git makes

24 it pretty easy (if nothing else, just clone the repository somewhere else,

25 and make sure that you do *not* use a hard-linked clone, and preferably

26 not the same disk/machine).

@@ -134,7 +134,7 @@ and your repository is good again!

134 git log --raw --all

135

136 and just looked for the sha of the missing object (4b9458b..) in that

137 -whole thing. It's up to you - git does *have* a lot of information, it is

137 +whole thing. It's up to you - Git does *have* a lot of information, it is

138 just missing one particular blob version.

139

140 Trying to recreate trees and especially commits is *much* harder. So you

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

+1 -1

@@ -164,7 +164,7 @@ merged. So it's debugging hell, because now you don't have lots of small

164 changes that you can try to pinpoint which _part_ of it changes.

165

166 But does it all work? Sure it does. You can revert a merge, and from a

167 -purely technical angle, git did it very naturally and had no real

167 +purely technical angle, Git did it very naturally and had no real

168 troubles. It just considered it a change from "state before merge" to

169 "state after merge", and that was it. Nothing complicated, nothing odd,

170 nothing really dangerous. Git will do it without even thinking about it.

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

+7 -7

@@ -1,9 +1,9 @@

1 From: Rutger Nijlunsing <rutger@nospam.com>

2 -Subject: Setting up a git repository which can be pushed into and pulled from over HTTP(S).

2 +Subject: Setting up a Git repository which can be pushed into and pulled from over HTTP(S).

3 Date: Thu, 10 Aug 2006 22:00:26 +0200

4 Content-type: text/asciidoc

6 -How to setup git server over http

6 +How to setup Git server over http

7 =================================

9 Since Apache is one of those packages people like to compile

@@ -44,9 +44,9 @@ What's needed:

45 - have permissions to chown a directory

47 -- have git installed on the client, and

47 +- have Git installed on the client, and

49 -- either have git installed on the server or have a webdav client on

49 +- either have Git installed on the server or have a webdav client on

50 the client.

52 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

57 -----------------------------------

59 At the time of writing, git-http-push cannot remotely create a Git

60 -repository. So we have to do that at the server side with git. Another

60 +repository. So we have to do that at the server side with Git. Another

61 option is to generate an empty bare repository at the client and copy

62 it to the server with a WebDAV client (which is the only option if Git

63 is not installed on the server).

@@ -189,7 +189,7 @@ http://<servername>/my-new-repo.git [x] Open as webfolder -> login .

189 Step 3: setup the client

190 ------------------------

191

192 -Make sure that you have HTTP support, i.e. your git was built with

192 +Make sure that you have HTTP support, i.e. your Git was built with

193 libcurl (version more recent than 7.10). The command 'git http-push' with

194 no argument should display a usage message.

195

@@ -268,7 +268,7 @@ Reading /usr/local/apache2/logs/error_log is often helpful.

268

269 On Debian: Read /var/log/apache2/error.log instead.

270

271 -If you access HTTPS locations, git may fail verifying the SSL

271 +If you access HTTPS locations, Git may fail verifying the SSL

272 certificate (this is return code 60). Setting http.sslVerify=false can

273 help diagnosing the problem, but removes security checks.

274

Documentation/howto/use-git-daemon.txt

+1 -1

@@ -4,7 +4,7 @@ How to use git-daemon

4 =====================

6 Git can be run in inetd mode and in stand alone mode. But all you want is

7 -let a coworker pull from you, and therefore need to set up a git server

7 +let a coworker pull from you, and therefore need to set up a Git server

8 real quick, right?

10 Note that git-daemon is not really chatty at the moment, especially when

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

+2 -2

@@ -23,7 +23,7 @@ Earlier, a typical pull request may have started like this:

24 Froboz 3.2 (2011-09-30 14:20:57 -0700)

26 - are available in the git repository at:

26 + are available in the Git repository at:

28 example.com:/git/froboz.git for-xyzzy

29 ------------

@@ -107,7 +107,7 @@ The resulting msg.txt file begins like so:

107

108 Froboz 3.2 (2011-09-30 14:20:57 -0700)

109

110 - are available in the git repository at:

110 + are available in the Git repository at:

111

112 example.com:/git/froboz.git tags/frotz-for-xyzzy

113

Documentation/i18n.txt

+4 -4

@@ -1,9 +1,9 @@

1 -At the core level, git is character encoding agnostic.

1 +At the core level, Git is character encoding agnostic.

3 - The pathnames recorded in the index and in the tree objects

4 are treated as uninterpreted sequences of non-NUL bytes.

5 What readdir(2) returns are what are recorded and compared

6 - with the data git keeps track of, which in turn are expected

6 + with the data Git keeps track of, which in turn are expected

7 to be what lstat(2) and creat(2) accepts. There is no such

8 thing as pathname encoding translation.

@@ -15,9 +15,9 @@ At the core level, git is character encoding agnostic.

15 bytes.

17 Although we encourage that the commit log messages are encoded

18 -in UTF-8, both the core and git Porcelain are designed not to

18 +in UTF-8, both the core and Git Porcelain are designed not to

19 force UTF-8 on projects. If all participants of a particular

20 -project find it more convenient to use legacy encodings, git

20 +project find it more convenient to use legacy encodings, Git

21 does not forbid it. However, there are a few things to keep in

22 mind.

Documentation/merge-config.txt

+4 -4

@@ -17,10 +17,10 @@ merge.defaultToUpstream::

17 these tracking branches are merged.

19 merge.ff::

20 - By default, git does not create an extra merge commit when merging

20 + By default, Git does not create an extra merge commit when merging

21 a commit that is a descendant of the current commit. Instead, the

22 tip of the current branch is fast-forwarded. When set to `false`,

23 - this variable tells git to create an extra merge commit in such

23 + this variable tells Git to create an extra merge commit in such

24 a case (equivalent to giving the `--no-ff` option from the command

25 line). When set to `only`, only such fast-forward merges are

26 allowed (equivalent to giving the `--ff-only` option from the

@@ -38,10 +38,10 @@ merge.renameLimit::

38 diff.renameLimit.

40 merge.renormalize::

41 - Tell git that canonical representation of files in the

41 + Tell Git that canonical representation of files in the

42 repository has changed over time (e.g. earlier commits record

43 text files with CRLF line endings, but recent ones use LF line

44 - endings). In such a repository, git can convert the data

44 + endings). In such a repository, Git can convert the data

45 recorded in commits to a canonical form before performing a

46 merge to reduce unnecessary conflicts. For more information,

47 see section "Merging branches with differing checkin/checkout

Documentation/rev-list-options.txt

+2 -2

@@ -649,7 +649,7 @@ together.

649 Object Traversal

650 ~~~~~~~~~~~~~~~~

651

652 -These options are mostly targeted for packing of git repositories.

652 +These options are mostly targeted for packing of Git repositories.

653

654 --objects::

655

@@ -717,7 +717,7 @@ format, often found in E-mail messages.

717 +

718 `--date=short` shows only date but not time, in `YYYY-MM-DD` format.

719 +

720 -`--date=raw` shows the date in the internal raw git format `%s %z` format.

720 +`--date=raw` shows the date in the internal raw Git format `%s %z` format.

721 +

722 `--date=default` shows timestamps in the original timezone

723 (either committer's or author's).

Documentation/revisions.txt

+1 -1

@@ -23,7 +23,7 @@ blobs contained in a commit.

23 A symbolic ref name. E.g. 'master' typically means the commit

24 object referenced by 'refs/heads/master'. If you

25 happen to have both 'heads/master' and 'tags/master', you can

26 - explicitly say 'heads/master' to tell git which one you mean.

26 + explicitly say 'heads/master' to tell Git which one you mean.

27 When ambiguous, a '<refname>' is disambiguated by taking the

28 first match in the following rules:

Documentation/technical/api-builtin.txt

+2 -2

@@ -5,7 +5,7 @@ Adding a new built-in

5 ---------------------

7 There are 4 things to do to add a built-in command implementation to

8 -git:

8 +Git:

10 . Define the implementation of the built-in command `foo` with

11 signature:

@@ -23,7 +23,7 @@ where options is the bitwise-or of:

24 `RUN_SETUP`::

26 - Make sure there is a git directory to work on, and if there is a

26 + Make sure there is a Git directory to work on, and if there is a

27 work tree, chdir to the top of it if the command was invoked

28 in a subdirectory. If there is no work tree, no chdir() is

29 done.

Documentation/technical/api-config.txt

+5 -5

@@ -1,7 +1,7 @@

1 config API

2 ==========

4 -The config API gives callers a way to access git configuration files

4 +The config API gives callers a way to access Git configuration files

5 (and files which have the same syntax). See linkgit:git-config[1] for a

6 discussion of the config file syntax.

@@ -12,7 +12,7 @@ Config files are parsed linearly, and each variable found is passed to a

12 caller-provided callback function. The callback function is responsible

13 for any actions to be taken on the config option, and is free to ignore

14 some options. It is not uncommon for the configuration to be parsed

15 -several times during the run of a git program, with different callbacks

15 +several times during the run of a Git program, with different callbacks

16 picking out different variables useful to themselves.

18 A config callback function takes three parameters:

@@ -36,7 +36,7 @@ Basic Config Querying

36 ---------------------

38 Most programs will simply want to look up variables in all config files

39 -that git knows about, using the normal precedence rules. To do this,

39 +that Git knows about, using the normal precedence rules. To do this,

40 call `git_config` with a callback function and void data pointer.

42 `git_config` will read all config sources in order of increasing

@@ -49,7 +49,7 @@ value is left at the end).

50 The `git_config_with_options` function lets the caller examine config

51 while adjusting some of the default behavior of `git_config`. It should

52 -almost never be used by "regular" git code that is looking up

52 +almost never be used by "regular" Git code that is looking up

53 configuration variables. It is intended for advanced callers like

54 `git-config`, which are intentionally tweaking the normal config-lookup

55 process. It takes two extra parameters:

@@ -66,7 +66,7 @@ Regular `git_config` defaults to `1`.

66 There is a special version of `git_config` called `git_config_early`.

67 This version takes an additional parameter to specify the repository

68 config, instead of having it looked up via `git_path`. This is useful

69 -early in a git program before the repository has been found. Unless

69 +early in a Git program before the repository has been found. Unless

70 you're working with early setup code, you probably don't want to use

71 this.

Documentation/technical/api-credentials.txt

+10 -10

@@ -7,9 +7,9 @@ world can take many forms, in this document the word "credential" always

7 refers to a username and password pair).

9 This document describes two interfaces: the C API that the credential

10 -subsystem provides to the rest of git, and the protocol that git uses to

10 +subsystem provides to the rest of Git, and the protocol that Git uses to

11 communicate with system-specific "credential helpers". If you are

12 -writing git code that wants to look up or prompt for credentials, see

12 +writing Git code that wants to look up or prompt for credentials, see

13 the section "C API" below. If you want to write your own helper, see

14 the section on "Credential Helpers" below.

@@ -18,7 +18,7 @@ Typical setup

19 ------------

20 +-----------------------+

21 -| git code (C) |--- to server requiring --->

21 +| Git code (C) |--- to server requiring --->

22 | | authentication

23 |.......................|

24 | C credential API |--- prompt ---> User

@@ -27,11 +27,11 @@ Typical setup

27 | pipe |

28 | v

29 +-----------------------+

30 -| git credential helper |

30 +| Git credential helper |

31 +-----------------------+

32 ------------

34 -The git code (typically a remote-helper) will call the C API to obtain

34 +The Git code (typically a remote-helper) will call the C API to obtain

35 credential data like a login/password pair (credential_fill). The

36 API will itself call a remote helper (e.g. "git credential-cache" or

37 "git credential-store") that may retrieve credential data from a

@@ -42,7 +42,7 @@ contacting the server, and does the actual authentication.

42 C API

43 -----

45 -The credential C API is meant to be called by git code which needs to

45 +The credential C API is meant to be called by Git code which needs to

46 acquire or store a credential. It is centered around an object

47 representing a single credential and provides three basic operations:

48 fill (acquire credentials by calling helpers and/or prompting the user),

@@ -177,14 +177,14 @@ int foo_login(struct foo_connection *f)

177 Credential Helpers

178 ------------------

179

180 -Credential helpers are programs executed by git to fetch or save

180 +Credential helpers are programs executed by Git to fetch or save

181 credentials from and to long-term storage (where "long-term" is simply

182 -longer than a single git process; e.g., credentials may be stored

182 +longer than a single Git process; e.g., credentials may be stored

183 in-memory for a few minutes, or indefinitely on disk).

184

185 Each helper is specified by a single string in the configuration

186 variable `credential.helper` (and others, see linkgit:git-config[1]).

187 -The string is transformed by git into a command to be executed using

187 +The string is transformed by Git into a command to be executed using

188 these rules:

189

190 1. If the helper string begins with "!", it is considered a shell

@@ -248,7 +248,7 @@ FORMAT` in linkgit:git-credential[7] for a detailed specification).

248 For a `get` operation, the helper should produce a list of attributes

249 on stdout in the same format. A helper is free to produce a subset, or

250 even no values at all if it has nothing useful to provide. Any provided

251 -attributes will overwrite those already known about by git.

251 +attributes will overwrite those already known about by Git.

252

253 For a `store` or `erase` operation, the helper's output is ignored.

254 If it fails to perform the requested operation, it may complain to

Documentation/technical/api-directory-listing.txt

+1 -1

@@ -39,7 +39,7 @@ The notable options are:

40 `DIR_NO_GITLINKS`:::

42 - If set, recurse into a directory that looks like a git

42 + If set, recurse into a directory that looks like a Git

43 directory. Otherwise it is shown as a directory.

45 The result of the enumeration is left in these fields:

Documentation/technical/api-parse-options.txt

+1 -1

@@ -1,7 +1,7 @@

1 parse-options API

2 =================

4 -The parse-options API is used to parse and massage options in git

4 +The parse-options API is used to parse and massage options in Git

5 and to provide a usage help with consistent look.

7 Basics

Documentation/technical/api-remote.txt

+2 -2

@@ -3,7 +3,7 @@ Remotes configuration API

4 The API in remote.h gives access to the configuration related to

5 remotes. It handles all three configuration mechanisms historically

6 -and currently used by git, and presents the information in a uniform

6 +and currently used by Git, and presents the information in a uniform

7 fashion. Note that the code also handles plain URLs without any

8 configuration, giving them just the default information.

@@ -45,7 +45,7 @@ struct remote

45 `receivepack`, `uploadpack`::

47 The configured helper programs to run on the remote side, for

48 - git-native protocols.

48 + Git-native protocols.

50 `http_proxy`::

Documentation/technical/index-format.txt

+1 -1

@@ -1,7 +1,7 @@

1 Git index format

2 ================

4 -== The git index file has the following format

4 +== The Git index file has the following format

6 All binary numbers are in network byte order. Version 2 is described

7 here unless stated otherwise.

Documentation/technical/pack-heuristics.txt

+10 -10

@@ -5,11 +5,11 @@

6 Where do I go

7 to learn the details

8 - of git's packing heuristics?

8 + of Git's packing heuristics?

10 Be careful what you ask!

12 -Followers of the git, please open the git IRC Log and turn to

12 +Followers of the Git, please open the Git IRC Log and turn to

13 February 10, 2006.

15 It's a rare occasion, and we are joined by the King Git Himself,

@@ -19,7 +19,7 @@ and seeks enlightenment. Others are present, but silent.

19 Let's listen in!

21 <njs`> Oh, here's a really stupid question -- where do I go to

22 - learn the details of git's packing heuristics? google avails

22 + learn the details of Git's packing heuristics? google avails

23 me not, reading the source didn't help a lot, and wading

24 through the whole mailing list seems less efficient than any

25 of that.

@@ -37,7 +37,7 @@ Ah! Modesty after all.

38 <linus> njs, I don't think the docs exist. That's something where

39 I don't think anybody else than me even really got involved.

40 - Most of the rest of git others have been busy with (especially

40 + Most of the rest of Git others have been busy with (especially

41 Junio), but packing nobody touched after I did it.

43 It's cryptic, yet vague. Linus in style for sure. Wise men

@@ -57,7 +57,7 @@ Bait...

58 And switch. That ought to do it!

60 - <linus> Remember: git really doesn't follow files. So what it does is

60 + <linus> Remember: Git really doesn't follow files. So what it does is

61 - generate a list of all objects

62 - sort the list according to magic heuristics

63 - walk the list, using a sliding window, seeing if an object

@@ -382,7 +382,7 @@ The 'net never forgets, so that should be good until the end of time.

382 <njs`> (if only it happened more...)

383

384 <linus> Anyway, the pack-file could easily be denser still, but

385 - because it's used both for streaming (the git protocol) and

385 + because it's used both for streaming (the Git protocol) and

386 for on-disk, it has a few pessimizations.

387

388 Actually, it is a made-up word. But it is a made-up word being

@@ -432,12 +432,12 @@ Gasp! OK, saved. That's a fair Engineering trade off. Close call!

432 In fact, Linus reflects on some Basic Engineering Fundamentals,

433 design options, etc.

434

435 - <linus> More importantly, they allow git to still _conceptually_

435 + <linus> More importantly, they allow Git to still _conceptually_

436 never deal with deltas at all, and be a "whole object" store.

437

438 Which has some problems (we discussed bad huge-file

439 - behaviour on the git lists the other day), but it does mean

440 - that the basic git concepts are really really simple and

439 + behaviour on the Git lists the other day), but it does mean

440 + that the basic Git concepts are really really simple and

441 straightforward.

442

443 It's all been quite stable.

@@ -461,6 +461,6 @@ Nuff said.

461 <njs`> :-)

462

463 <njs`> appreciate the infodump, I really was failing to find the

464 - details on git packs :-)

464 + details on Git packs :-)

465

466 And now you know the rest of the story.

Documentation/technical/racy-git.txt

+13 -13

@@ -1,21 +1,21 @@

1 -Use of index and Racy git problem

1 +Use of index and Racy Git problem

2 =================================

4 Background

5 ----------

7 -The index is one of the most important data structures in git.

7 +The index is one of the most important data structures in Git.

8 It represents a virtual working tree state by recording list of

9 paths and their object names and serves as a staging area to

10 write out the next tree object to be committed. The state is

11 "virtual" in the sense that it does not necessarily have to, and

12 often does not, match the files in the working tree.

14 -There are cases git needs to examine the differences between the

14 +There are cases Git needs to examine the differences between the

15 virtual working tree state in the index and the files in the

16 working tree. The most obvious case is when the user asks `git

17 diff` (or its low level implementation, `git diff-files`) or

18 -`git-ls-files --modified`. In addition, git internally checks

18 +`git-ls-files --modified`. In addition, Git internally checks

19 if the files in the working tree are different from what are

20 recorded in the index to avoid stomping on local changes in them

21 during patch application, switching branches, and merging.

@@ -24,16 +24,16 @@ In order to speed up this comparison between the files in the

24 working tree and the index entries, the index entries record the

25 information obtained from the filesystem via `lstat(2)` system

26 call when they were last updated. When checking if they differ,

27 -git first runs `lstat(2)` on the files and compares the result

27 +Git first runs `lstat(2)` on the files and compares the result

28 with this information (this is what was originally done by the

29 `ce_match_stat()` function, but the current code does it in

30 `ce_match_stat_basic()` function). If some of these "cached

31 -stat information" fields do not match, git can tell that the

31 +stat information" fields do not match, Git can tell that the

32 files are modified without even looking at their contents.

34 Note: not all members in `struct stat` obtained via `lstat(2)`

35 are used for this comparison. For example, `st_atime` obviously

36 -is not useful. Currently, git compares the file type (regular

36 +is not useful. Currently, Git compares the file type (regular

37 files vs symbolic links) and executable bits (only for regular

38 files) from `st_mode` member, `st_mtime` and `st_ctime`

39 timestamps, `st_uid`, `st_gid`, `st_ino`, and `st_size` members.

@@ -49,7 +49,7 @@ of git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git

49 ([PATCH] Sync in core time granuality with filesystems,

50 2005-01-04).

52 -Racy git

52 +Racy Git

53 --------

55 There is one slight problem with the optimization based on the

@@ -67,13 +67,13 @@ timestamp does not change, after this sequence, the cached stat

67 information the index entry records still exactly match what you

68 would see in the filesystem, even though the file `foo` is now

69 different.

70 -This way, git can incorrectly think files in the working tree

70 +This way, Git can incorrectly think files in the working tree

71 are unmodified even though they actually are. This is called

72 -the "racy git" problem (discovered by Pasky), and the entries

72 +the "racy Git" problem (discovered by Pasky), and the entries

73 that appear clean when they may not be because of this problem

74 are called "racily clean".

76 -To avoid this problem, git does two things:

76 +To avoid this problem, Git does two things:

78 . When the cached stat information says the file has not been

79 modified, and the `st_mtime` is the same as (or newer than)

@@ -116,7 +116,7 @@ timestamp comparison check done with the former logic anymore.

116 The latter makes sure that the cached stat information for `foo`

117 would never match with the file in the working tree, so later

118 checks by `ce_match_stat_basic()` would report that the index entry

119 -does not match the file and git does not have to fall back on more

119 +does not match the file and Git does not have to fall back on more

120 expensive `ce_modified_check_fs()`.

121

122

@@ -159,7 +159,7 @@ of the cached stat information.

159 Avoiding runtime penalty

160 ------------------------

161

162 -In order to avoid the above runtime penalty, post 1.4.2 git used

162 +In order to avoid the above runtime penalty, post 1.4.2 Git used

163 to have a code that made sure the index file

164 got timestamp newer than the youngest files in the index when

165 there are many young files with the same timestamp as the

Documentation/urls-remotes.txt

+1 -1

@@ -6,7 +6,7 @@ REMOTES[[REMOTES]]

6 The name of one of the following can be used instead

7 of a URL as `<repository>` argument:

9 -* a remote in the git configuration file: `$GIT_DIR/config`,

9 +* a remote in the Git configuration file: `$GIT_DIR/config`,

10 * a file in the `$GIT_DIR/remotes` directory, or

11 * a file in the `$GIT_DIR/branches` directory.

Documentation/urls.txt

+2 -2

@@ -29,7 +29,7 @@ The ssh and git protocols additionally support ~username expansion:

29 - git://host.xz{startsb}:port{endsb}/~{startsb}user{endsb}/path/to/repo.git/

30 - {startsb}user@{endsb}host.xz:/~{startsb}user{endsb}/path/to/repo.git/

32 -For local repositories, also supported by git natively, the following

32 +For local repositories, also supported by Git natively, the following

33 syntaxes may be used:

35 - /path/to/repo.git/

@@ -46,7 +46,7 @@ These two syntaxes are mostly equivalent, except the former implies

46 --local option.

47 endif::git-clone[]

49 -When git doesn't know how to handle a certain transport protocol, it

49 +When Git doesn't know how to handle a certain transport protocol, it

50 attempts to use the 'remote-<transport>' remote helper, if one

51 exists. To explicitly request a remote helper, the following syntax

52 may be used:

Documentation/user-manual.txt

+106 -106

@@ -5,7 +5,7 @@ ______________________________________________

5 Git is a fast distributed revision control system.

7 This manual is designed to be readable by someone with basic UNIX

8 -command-line skills, but no previous knowledge of git.

8 +command-line skills, but no previous knowledge of Git.

10 <<repositories-and-branches>> and <<exploring-git-history>> explain how

11 to fetch and study a project using git--read these chapters to learn how

@@ -34,7 +34,7 @@ $ git help clone

34 With the latter, you can use the manual viewer of your choice; see

35 linkgit:git-help[1] for more information.

37 -See also <<git-quick-start>> for a brief overview of git commands,

37 +See also <<git-quick-start>> for a brief overview of Git commands,

38 without any explanation.

40 Finally, see <<todo>> for ways that you can help make this manual more

@@ -46,10 +46,10 @@ Repositories and Branches

46 =========================

48 [[how-to-get-a-git-repository]]

49 -How to get a git repository

49 +How to get a Git repository

50 ---------------------------

52 -It will be useful to have a git repository to experiment with as you

52 +It will be useful to have a Git repository to experiment with as you

53 read this manual.

55 The best way to get one is by using the linkgit:git-clone[1] command to

@@ -57,7 +57,7 @@ download a copy of an existing repository. If you don't already have a

57 project in mind, here are some interesting examples:

59 ------------------------------------------------

60 - # git itself (approx. 10MB download):

60 + # Git itself (approx. 10MB download):

61 $ git clone git://git.kernel.org/pub/scm/git/git.git

62 # the Linux kernel (approx. 150MB download):

63 $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

@@ -79,7 +79,7 @@ How to check out a different version of a project

80 Git is best thought of as a tool for storing the history of a collection

81 of files. It stores the history as a compressed collection of

82 -interrelated snapshots of the project's contents. In git each such

82 +interrelated snapshots of the project's contents. In Git each such

83 version is called a <<def_commit,commit>>.

85 Those snapshots aren't necessarily all arranged in a single line from

@@ -87,7 +87,7 @@ oldest to newest; instead, work may simultaneously proceed along

87 parallel lines of development, called <<def_branch,branches>>, which may

88 merge and diverge.

90 -A single git repository can track development on multiple branches. It

90 +A single Git repository can track development on multiple branches. It

91 does this by keeping a list of <<def_head,heads>> which reference the

92 latest commit on each branch; the linkgit:git-branch[1] command shows

93 you the list of branch heads:

@@ -198,7 +198,7 @@ has that commit at all). Since the object name is computed as a hash over the

198 contents of the commit, you are guaranteed that the commit can never change

199 without its name also changing.

200

201 -In fact, in <<git-concepts>> we shall see that everything stored in git

201 +In fact, in <<git-concepts>> we shall see that everything stored in Git

202 history, including file data and directory contents, is stored in an object

203 with a name that is a hash of its contents.

204

@@ -211,7 +211,7 @@ parent commit which shows what happened before this commit.

211 Following the chain of parents will eventually take you back to the

212 beginning of the project.

213

214 -However, the commits do not form a simple list; git allows lines of

214 +However, the commits do not form a simple list; Git allows lines of

215 development to diverge and then reconverge, and the point where two

216 lines of development reconverge is called a "merge". The commit

217 representing a merge can therefore have more than one parent, with

@@ -219,8 +219,8 @@ each parent representing the most recent commit on one of the lines

219 of development leading to that point.

220

221 The best way to see how this works is using the linkgit:gitk[1]

222 -command; running gitk now on a git repository and looking for merge

223 -commits will help understand how the git organizes history.

222 +command; running gitk now on a Git repository and looking for merge

223 +commits will help understand how the Git organizes history.

224

225 In the following, we say that commit X is "reachable" from commit Y

226 if commit X is an ancestor of commit Y. Equivalently, you could say

@@ -231,7 +231,7 @@ leading from commit Y to commit X.

231 Understanding history: History diagrams

232 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

233

234 -We will sometimes represent git history using diagrams like the one

234 +We will sometimes represent Git history using diagrams like the one

235 below. Commits are shown as "o", and the links between them with

236 lines drawn with - / and \. Time goes left to right:

237

@@ -285,7 +285,7 @@ git branch -D <branch>::

285 even if the branch points to a commit not reachable

286 from the current branch, you may know that that commit

287 is still reachable from some other branch or tag. In that

288 - case it is safe to use this command to force git to delete

288 + case it is safe to use this command to force Git to delete

289 the branch.

290 git checkout <branch>::

291 make the current branch <branch>, updating the working

@@ -295,7 +295,7 @@ git checkout -b <new> <start-point>::

295 check it out.

296

297 The special symbol "HEAD" can always be used to refer to the current

298 -branch. In fact, git uses a file named "HEAD" in the .git directory to

298 +branch. In fact, Git uses a file named "HEAD" in the .git directory to

299 remember which branch is current:

300

301 ------------------------------------------------

@@ -377,7 +377,7 @@ $ git checkout -b my-todo-copy origin/todo

377 You can also check out "origin/todo" directly to examine it or

378 write a one-off patch. See <<detached-head,detached head>>.

379

380 -Note that the name "origin" is just the name that git uses by default

380 +Note that the name "origin" is just the name that Git uses by default

381 to refer to the repository that you cloned from.

382

383 [[how-git-stores-references]]

@@ -405,7 +405,7 @@ As another useful shortcut, the "HEAD" of a repository can be referred

405 to just using the name of that repository. So, for example, "origin"

406 is usually a shortcut for the HEAD branch in the repository "origin".

407

408 -For the complete list of paths which git checks for references, and

408 +For the complete list of paths which Git checks for references, and

409 the order it uses to decide which to choose when there are multiple

410 references with the same shorthand name, see the "SPECIFYING

411 REVISIONS" section of linkgit:gitrevisions[7].

@@ -449,7 +449,7 @@ origin/master

449 If you run "git fetch <remote>" later, the remote-tracking branches for the

450 named <remote> will be updated.

451

452 -If you examine the file .git/config, you will see that git has added

452 +If you examine the file .git/config, you will see that Git has added

453 a new stanza:

454

455 -------------------------------------------------

@@ -461,13 +461,13 @@ $ cat .git/config

461 ...

462 -------------------------------------------------

463

464 -This is what causes git to track the remote's branches; you may modify

464 +This is what causes Git to track the remote's branches; you may modify

465 or delete these configuration options by editing .git/config with a

466 text editor. (See the "CONFIGURATION FILE" section of

467 linkgit:git-config[1] for details.)

468

469 [[exploring-git-history]]

470 -Exploring git history

470 +Exploring Git history

471 =====================

472

473 Git is best thought of as a tool for storing the history of a

@@ -499,7 +499,7 @@ Bisecting: 3537 revisions left to test after this

499 [65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6]

500 -------------------------------------------------

501

502 -If you run "git branch" at this point, you'll see that git has

502 +If you run "git branch" at this point, you'll see that Git has

503 temporarily moved you in "(no branch)". HEAD is now detached from any

504 branch and points directly to a commit (with commit id 65934...) that

505 is reachable from "master" but not from v2.6.18. Compile and test it,

@@ -511,7 +511,7 @@ Bisecting: 1769 revisions left to test after this

511 [7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless bitmaskings

512 -------------------------------------------------

513

514 -checks out an older version. Continue like this, telling git at each

514 +checks out an older version. Continue like this, telling Git at each

515 stage whether the version it gives you is good or bad, and notice

516 that the number of revisions left to test is cut approximately in

517 half each time.

@@ -549,14 +549,14 @@ then test, run "bisect good" or "bisect bad" as appropriate, and

549 continue.

550

551 Instead of "git bisect visualize" and then "git reset --hard

552 -fb47ddb2db...", you might just want to tell git that you want to skip

552 +fb47ddb2db...", you might just want to tell Git that you want to skip

553 the current commit:

554

555 -------------------------------------------------

556 $ git bisect skip

557 -------------------------------------------------

558

559 -In this case, though, git may not eventually be able to tell the first

559 +In this case, though, Git may not eventually be able to tell the first

560 bad one between some first skipped commits and a later bad commit.

561

562 There are also ways to automate the bisecting process if you have a

@@ -685,7 +685,7 @@ See the "--pretty" option in the linkgit:git-log[1] man page for more

685 display options.

686

687 Note that git log starts with the most recent commit and works

688 -backwards through the parents; however, since git history can contain

688 +backwards through the parents; however, since Git history can contain

689 multiple independent lines of development, the particular order that

690 commits are listed in may be somewhat arbitrary.

691

@@ -732,7 +732,7 @@ $ git show v2.5:fs/locks.c

732 -------------------------------------------------

733

734 Before the colon may be anything that names a commit, and after it

735 -may be any path to a file tracked by git.

735 +may be any path to a file tracked by Git.

736

737 [[history-examples]]

738 Examples

@@ -984,14 +984,14 @@ student. The linkgit:git-log[1], linkgit:git-diff-tree[1], and

984 linkgit:git-hash-object[1] man pages may prove helpful.

985

986 [[Developing-With-git]]

987 -Developing with git

987 +Developing with Git

988 ===================

989

990 [[telling-git-your-name]]

991 -Telling git your name

991 +Telling Git your name

992 ---------------------

993

994 -Before creating any commits, you should introduce yourself to git. The

994 +Before creating any commits, you should introduce yourself to Git. The

995 easiest way to do so is to make sure the following lines appear in a

996 file named .gitconfig in your home directory:

997

@@ -1035,13 +1035,13 @@ Creating a new commit takes three steps:

1035

1036 1. Making some changes to the working directory using your

1037 favorite editor.

1038 - 2. Telling git about your changes.

1039 - 3. Creating the commit using the content you told git about

1038 + 2. Telling Git about your changes.

1039 + 3. Creating the commit using the content you told Git about

1040 in step 2.

1041

1042 In practice, you can interleave and repeat steps 1 and 2 as many

1043 times as you want: in order to keep track of what you want committed

1044 -at step 3, git maintains a snapshot of the tree's contents in a

1044 +at step 3, Git maintains a snapshot of the tree's contents in a

1045 special staging area called "the index."

1046

1047 At the beginning, the content of the index will be identical to

@@ -1094,7 +1094,7 @@ When you're ready, just run

1094 $ git commit

1095 -------------------------------------------------

1096

1097 -and git will prompt you for a commit message and then create the new

1097 +and Git will prompt you for a commit message and then create the new

1098 commit. Check to make sure it looks like what you expected with

1099

1100 -------------------------------------------------

@@ -1138,7 +1138,7 @@ with a single short (less than 50 character) line summarizing the

1138 change, followed by a blank line and then a more thorough

1139 description. The text up to the first blank line in a commit

1140 message is treated as the commit title, and that title is used

1141 -throughout git. For example, linkgit:git-format-patch[1] turns a

1141 +throughout Git. For example, linkgit:git-format-patch[1] turns a

1142 commit into email, and it uses the title on the Subject line and the

1143 rest of the commit in the body.

1144

@@ -1147,15 +1147,15 @@ rest of the commit in the body.

1147 Ignoring files

1148 --------------

1149

1150 -A project will often generate files that you do 'not' want to track with git.

1150 +A project will often generate files that you do 'not' want to track with Git.

1151 This typically includes files generated by a build process or temporary

1152 -backup files made by your editor. Of course, 'not' tracking files with git

1152 +backup files made by your editor. Of course, 'not' tracking files with Git

1153 is just a matter of 'not' calling `git add` on them. But it quickly becomes

1154 annoying to have these untracked files lying around; e.g. they make

1155 `git add .` practically useless, and they keep showing up in the output of

1156 `git status`.

1157

1158 -You can tell git to ignore certain files by creating a file called .gitignore

1158 +You can tell Git to ignore certain files by creating a file called .gitignore

1159 in the top level of your working directory, with contents such as:

1160

1161 -------------------------------------------------

@@ -1181,7 +1181,7 @@ for other users who clone your repository.

1181 If you wish the exclude patterns to affect only certain repositories

1182 (instead of every repository for a given project), you may instead put

1183 them in a file in your repository named .git/info/exclude, or in any file

1184 -specified by the `core.excludesfile` configuration variable. Some git

1184 +specified by the `core.excludesfile` configuration variable. Some Git

1185 commands can also take exclude patterns directly on the command line.

1186 See linkgit:gitignore[5] for the details.

1187

@@ -1227,7 +1227,7 @@ Automatic merge failed; fix conflicts and then commit the result.

1227

1228 Conflict markers are left in the problematic files, and after

1229 you resolve the conflicts manually, you can update the index

1230 -with the contents and run git commit, as you normally would when

1230 +with the contents and run Git commit, as you normally would when

1231 creating a new file.

1232

1233 If you examine the resulting commit using gitk, you will see that it

@@ -1238,7 +1238,7 @@ one to the top of the other branch.

1238 Resolving a merge

1239 -----------------

1240

1241 -When a merge isn't resolved automatically, git leaves the index and

1241 +When a merge isn't resolved automatically, Git leaves the index and

1242 the working tree in a special state that gives you all the

1243 information you need to help resolve the merge.

1244

@@ -1274,14 +1274,14 @@ some information about the merge. Normally you can just use this

1274 default message unchanged, but you may add additional commentary of

1275 your own if desired.

1276

1277 -The above is all you need to know to resolve a simple merge. But git

1277 +The above is all you need to know to resolve a simple merge. But Git

1278 also provides more information to help resolve conflicts:

1279

1280 [[conflict-resolution]]

1281 Getting conflict-resolution help during a merge

1282 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1283

1284 -All of the changes that git was able to merge automatically are

1284 +All of the changes that Git was able to merge automatically are

1285 already added to the index file, so linkgit:git-diff[1] shows only

1286 the conflicts. It uses an unusual syntax:

1287

@@ -1413,7 +1413,7 @@ parents, one pointing at each of the two lines of development that

1413 were merged.

1414

1415 However, if the current branch is a descendant of the other--so every

1416 -commit present in the one is already contained in the other--then git

1416 +commit present in the one is already contained in the other--then Git

1417 just performs a "fast-forward"; the head of the current branch is moved

1418 forward to point at the head of the merged-in branch, without any new

1419 commits being created.

@@ -1439,7 +1439,7 @@ fundamentally different ways to fix the problem:

1439

1440 2. You can go back and modify the old commit. You should

1441 never do this if you have already made the history public;

1442 - git does not normally expect the "history" of a project to

1442 + Git does not normally expect the "history" of a project to

1443 change, and cannot correctly perform repeated merges from

1444 a branch that has had its history changed.

1445

@@ -1464,7 +1464,7 @@ You can also revert an earlier change, for example, the next-to-last:

1464 $ git revert HEAD^

1465 -------------------------------------------------

1466

1467 -In this case git will attempt to undo the old change while leaving

1467 +In this case Git will attempt to undo the old change while leaving

1468 intact any changes made since then. If more recent changes overlap

1469 with the changes to be reverted, then you will be asked to fix

1470 conflicts manually, just as in the case of <<resolving-a-merge,

@@ -1561,7 +1561,7 @@ $ git stash pop

1561 Ensuring good performance

1562 -------------------------

1563

1564 -On large repositories, git depends on compression to keep the history

1564 +On large repositories, Git depends on compression to keep the history

1565 information from taking up too much space on disk or in memory.

1566

1567 This compression is not performed automatically. Therefore you

@@ -1618,7 +1618,7 @@ Say you modify a branch with +linkgit:git-reset[1] \--hard+, and then

1618 realize that the branch was the only reference you had to that point in

1619 history.

1620

1621 -Fortunately, git also keeps a log, called a "reflog", of all the

1621 +Fortunately, Git also keeps a log, called a "reflog", of all the

1622 previous values of each branch. So in this case you can still find the

1623 old history using, for example,

1624

@@ -1627,7 +1627,7 @@ $ git log master@{1}

1627 -------------------------------------------------

1628

1629 This lists the commits reachable from the previous version of the

1630 -"master" branch head. This syntax can be used with any git command

1630 +"master" branch head. This syntax can be used with any Git command

1631 that accepts a commit, not just with git log. Some other examples:

1632

1633 -------------------------------------------------

@@ -1653,7 +1653,7 @@ pruned. See linkgit:git-reflog[1] and linkgit:git-gc[1] to learn

1653 how to control this pruning, and see the "SPECIFYING REVISIONS"

1654 section of linkgit:gitrevisions[7] for details.

1655

1656 -Note that the reflog history is very different from normal git history.

1656 +Note that the reflog history is very different from normal Git history.

1657 While normal history is shared by every repository that works on the

1658 same project, the reflog history is not shared: it tells you only about

1659 how the branches in your local repository have changed over time.

@@ -1816,7 +1816,7 @@ $ git am -3 patches.mbox

1816 Git will apply each patch in order; if any conflicts are found, it

1817 will stop, and you can fix the conflicts as described in

1818 "<<resolving-a-merge,Resolving a merge>>". (The "-3" option tells

1819 -git to perform a merge; if you would prefer it just to abort and

1819 +Git to perform a merge; if you would prefer it just to abort and

1820 leave your tree and index untouched, you may omit that option.)

1821

1822 Once the index is updated with the results of the conflict

@@ -1826,7 +1826,7 @@ resolution, instead of creating a new commit, just run

1826 $ git am --resolved

1827 -------------------------------------------------

1828

1829 -and git will create the commit for you and continue applying the

1829 +and Git will create the commit for you and continue applying the

1830 remaining patches from the mailbox.

1831

1832 The final result will be a series of commits, one for each patch in

@@ -1834,7 +1834,7 @@ the original mailbox, with authorship and commit log message each

1834 taken from the message containing each patch.

1835

1836 [[public-repositories]]

1837 -Public git repositories

1837 +Public Git repositories

1838 -----------------------

1839

1840 Another way to submit changes to a project is to tell the maintainer

@@ -1909,7 +1909,7 @@ public repository. You can use scp, rsync, or whatever is most

1909 convenient.

1910

1911 [[exporting-via-git]]

1912 -Exporting a git repository via the git protocol

1912 +Exporting a Git repository via the Git protocol

1913 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1914

1915 This is the preferred method.

@@ -1922,7 +1922,7 @@ repository>>", below.

1922

1923 Otherwise, all you need to do is start linkgit:git-daemon[1]; it will

1924 listen on port 9418. By default, it will allow access to any directory

1925 -that looks like a git directory and contains the magic file

1925 +that looks like a Git directory and contains the magic file

1926 git-daemon-export-ok. Passing some directory paths as `git daemon`

1927 arguments will further restrict the exports to those paths.

1928

@@ -1931,13 +1931,13 @@ linkgit:git-daemon[1] man page for details. (See especially the

1931 examples section.)

1932

1933 [[exporting-via-http]]

1934 -Exporting a git repository via http

1934 +Exporting a Git repository via http

1935 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1936

1937 -The git protocol gives better performance and reliability, but on a

1937 +The Git protocol gives better performance and reliability, but on a

1938 host with a web server set up, http exports may be simpler to set up.

1939

1940 -All you need to do is place the newly created bare git repository in

1940 +All you need to do is place the newly created bare Git repository in

1941 a directory that is exported by the web server, and make some

1942 adjustments to give web clients some extra information they need:

1943

@@ -2073,9 +2073,9 @@ all push to and pull from a single shared repository. See

2073 linkgit:gitcvs-migration[7] for instructions on how to

2074 set this up.

2075

2076 -However, while there is nothing wrong with git's support for shared

2076 +However, while there is nothing wrong with Git's support for shared

2077 repositories, this mode of operation is not generally recommended,

2078 -simply because the mode of collaboration that git supports--by

2078 +simply because the mode of collaboration that Git supports--by

2079 exchanging patches and pulling from public repositories--has so many

2080 advantages over the central shared repository:

2081

@@ -2099,8 +2099,8 @@ Allowing web browsing of a repository

2099 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2100

2101 The gitweb cgi script provides users an easy way to browse your

2102 -project's files and history without having to install git; see the file

2103 -gitweb/INSTALL in the git source tree for instructions on setting it up.

2102 +project's files and history without having to install Git; see the file

2103 +gitweb/INSTALL in the Git source tree for instructions on setting it up.

2104

2105 [[sharing-development-examples]]

2106 Examples

@@ -2110,7 +2110,7 @@ Examples

2110 Maintaining topic branches for a Linux subsystem maintainer

2111 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2112

2113 -This describes how Tony Luck uses git in his role as maintainer of the

2113 +This describes how Tony Luck uses Git in his role as maintainer of the

2114 IA64 architecture for the Linux kernel.

2115

2116 He uses two public branches:

@@ -2160,7 +2160,7 @@ $ git checkout release && git pull

2160

2161 Important note! If you have any local changes in these branches, then

2162 this merge will create a commit object in the history (with no local

2163 -changes git will simply do a "fast-forward" merge). Many people dislike

2163 +changes Git will simply do a "fast-forward" merge). Many people dislike

2164 the "noise" that this creates in the Linux history, so you should avoid

2165 doing this capriciously in the "release" branch, as these noisy commits

2166 will become part of the permanent history when you ask Linus to pull

@@ -2413,7 +2413,7 @@ Rewriting history and maintaining patch series

2413

2414 Normally commits are only added to a project, never taken away or

2415 replaced. Git is designed with this assumption, and violating it will

2416 -cause git's merge machinery (for example) to do the wrong thing.

2416 +cause Git's merge machinery (for example) to do the wrong thing.

2417

2418 However, there is a situation in which it can be useful to violate this

2419 assumption.

@@ -2524,7 +2524,7 @@ running `git commit`, just run

2524 $ git rebase --continue

2525 -------------------------------------------------

2526

2527 -and git will continue applying the rest of the patches.

2527 +and Git will continue applying the rest of the patches.

2528

2529 At any point you may use the `--abort` option to abort this process and

2530 return mywork to the state it had before you started the rebase:

@@ -2577,7 +2577,7 @@ then clean up with

2577 $ git tag -d bad

2578 -------------------------------------------------

2579

2580 -Note that the immutable nature of git history means that you haven't really

2580 +Note that the immutable nature of Git history means that you haven't really

2581 "modified" existing commits; instead, you have replaced the old commits with

2582 new commits having new object names.

2583

@@ -2658,7 +2658,7 @@ Git has no way of knowing that the new head is an updated version of

2658 the old head; it treats this situation exactly the same as it would if

2659 two developers had independently done the work on the old and new heads

2660 in parallel. At this point, if someone attempts to merge the new head

2661 -in to their branch, git will attempt to merge together the two (old and

2661 +in to their branch, Git will attempt to merge together the two (old and

2662 new) lines of development, instead of trying to replace the old by the

2663 new. The results are likely to be unexpected.

2664

@@ -2731,7 +2731,7 @@ linear history:

2731 Bisecting between Z and D* would hit a single culprit commit Y*,

2732 and understanding why Y* was broken would probably be easier.

2733

2734 -Partly for this reason, many experienced git users, even when

2734 +Partly for this reason, many experienced Git users, even when

2735 working on an otherwise merge-heavy project, keep the history

2736 linear by rebasing against the latest upstream version before

2737 publishing.

@@ -2752,8 +2752,8 @@ arbitrary name:

2752 $ git fetch origin todo:my-todo-work

2753 -------------------------------------------------

2754

2755 -The first argument, "origin", just tells git to fetch from the

2756 -repository you originally cloned from. The second argument tells git

2755 +The first argument, "origin", just tells Git to fetch from the

2756 +repository you originally cloned from. The second argument tells Git

2757 to fetch the branch named "todo" from the remote repository, and to

2758 store it locally under the name refs/heads/my-todo-work.

2759

@@ -2801,7 +2801,7 @@ resulting in a situation like:

2801

2802 In this case, "git fetch" will fail, and print out a warning.

2803

2804 -In that case, you can still force git to update to the new head, as

2804 +In that case, you can still force Git to update to the new head, as

2805 described in the following section. However, note that in the

2806 situation above this may mean losing the commits labeled "a" and "b",

2807 unless you've already created a reference of your own pointing to

@@ -2834,7 +2834,7 @@ Configuring remote-tracking branches

2834

2835 We saw above that "origin" is just a shortcut to refer to the

2836 repository that you originally cloned from. This information is

2837 -stored in git configuration variables, which you can see using

2837 +stored in Git configuration variables, which you can see using

2838 linkgit:git-config[1]:

2839

2840 -------------------------------------------------

@@ -2900,7 +2900,7 @@ Git concepts

2900

2901 Git is built on a small number of simple but powerful ideas. While it

2902 is possible to get things done without understanding them, you will find

2903 -git much more intuitive if you do.

2903 +Git much more intuitive if you do.

2904

2905 We start with the most important, the <<def_object_database,object

2906 database>> and the <<def_index,index>>.

@@ -2994,7 +2994,7 @@ As you can see, a commit is defined by:

2994 Note that a commit does not itself contain any information about what

2995 actually changed; all changes are calculated by comparing the contents

2996 of the tree referred to by this commit with the trees associated with

2997 -its parents. In particular, git does not attempt to record file renames

2997 +its parents. In particular, Git does not attempt to record file renames

2998 explicitly, though it can identify cases where the existence of the same

2999 file data at changing paths suggests a rename. (See, for example, the

3000 -M option to linkgit:git-diff[1]).

@@ -3033,14 +3033,14 @@ another tree, representing the contents of a subdirectory. Since trees

3033 and blobs, like all other objects, are named by the SHA-1 hash of their

3034 contents, two trees have the same SHA-1 name if and only if their

3035 contents (including, recursively, the contents of all subdirectories)

3036 -are identical. This allows git to quickly determine the differences

3036 +are identical. This allows Git to quickly determine the differences

3037 between two related tree objects, since it can ignore any entries with

3038 identical object names.

3039

3040 (Note: in the presence of submodules, trees may also have commits as

3041 entries. See <<submodules>> for documentation.)

3042

3043 -Note that the files all have mode 644 or 755: git actually only pays

3043 +Note that the files all have mode 644 or 755: Git actually only pays

3044 attention to the executable bit.

3045

3046 [[blob-object]]

@@ -3101,7 +3101,7 @@ sending out a single email that tells the people the name (SHA-1 hash)

3101 of the top commit, and digitally sign that email using something

3102 like GPG/PGP.

3103

3104 -To assist in this, git also provides the tag object...

3104 +To assist in this, Git also provides the tag object...

3105

3106 [[tag-object]]

3107 Tag Object

@@ -3134,7 +3134,7 @@ objects. (Note that linkgit:git-tag[1] can also be used to create

3134 references whose names begin with "refs/tags/").

3135

3136 [[pack-files]]

3137 -How git stores objects efficiently: pack files

3137 +How Git stores objects efficiently: pack files

3138 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3139

3140 Newly created objects are initially created in a file named after the

@@ -3152,7 +3152,7 @@ The first number is the number of objects which are kept in

3152 individual files. The second is the amount of space taken up by

3153 those "loose" objects.

3154

3155 -You can save space and make git faster by moving these loose objects in

3155 +You can save space and make Git faster by moving these loose objects in

3156 to a "pack file", which stores a group of objects in an efficient

3157 compressed format; the details of how pack files are formatted can be

3158 found in link:technical/pack-format.txt[technical/pack-format.txt].

@@ -3285,12 +3285,12 @@ repository is a *BAD* idea).

3285 Recovering from repository corruption

3286 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3287

3288 -By design, git treats data trusted to it with caution. However, even in

3289 -the absence of bugs in git itself, it is still possible that hardware or

3288 +By design, Git treats data trusted to it with caution. However, even in

3289 +the absence of bugs in Git itself, it is still possible that hardware or

3290 operating system errors could corrupt data.

3291

3292 The first defense against such problems is backups. You can back up a

3293 -git directory using clone, or just using cp, tar, or any other backup

3293 +Git directory using clone, or just using cp, tar, or any other backup

3294 mechanism.

3295

3296 As a last resort, you can search for the corrupted objects and attempt

@@ -3396,7 +3396,7 @@ $ git log --raw --all

3396 ------------------------------------------------

3397

3398 and just looked for the sha of the missing object (4b9458b..) in that

3399 -whole thing. It's up to you - git does *have* a lot of information, it is

3399 +whole thing. It's up to you - Git does *have* a lot of information, it is

3400 just missing one particular blob version.

3401

3402 [[the-index]]

@@ -3438,7 +3438,7 @@ It does this by storing some additional data for each entry (such as

3438 the last modified time). This data is not displayed above, and is not

3439 stored in the created tree object, but it can be used to determine

3440 quickly which files in the working directory differ from what was

3441 -stored in the index, and thus save git from having to read all of the

3441 +stored in the index, and thus save Git from having to read all of the

3442 data from such files to look for changes.

3443

3444 3. It can efficiently represent information about merge conflicts

@@ -3669,9 +3669,9 @@ Did you forget to 'git add'?

3669 Unable to checkout '261dfac35cb99d380eb966e102c1197139f7fa24' in submodule path 'a'

3670 -------------------------------------------------

3671

3672 -In older git versions it could be easily forgotten to commit new or modified

3672 +In older Git versions it could be easily forgotten to commit new or modified

3673 files in a submodule, which silently leads to similar problems as not pushing

3674 -the submodule changes. Starting with git 1.7.0 both "git status" and "git diff"

3674 +the submodule changes. Starting with Git 1.7.0 both "git status" and "git diff"

3675 in the superproject show submodules as modified when they contain new or

3676 modified files to protect against accidentally committing such a state. "git

3677 diff" will also add a "-dirty" to the work tree side when generating patch

@@ -3714,12 +3714,12 @@ NOTE: The changes are still visible in the submodule's reflog.

3714 This is not the case if you did not commit your changes.

3715

3716 [[low-level-operations]]

3717 -Low-level git operations

3717 +Low-level Git operations

3718 ========================

3719

3720 Many of the higher-level commands were originally implemented as shell

3721 -scripts using a smaller core of low-level git commands. These can still

3722 -be useful when doing unusual things with git, or just as a way to

3721 +scripts using a smaller core of low-level Git commands. These can still

3722 +be useful when doing unusual things with Git, or just as a way to

3723 understand its inner workings.

3724

3725 [[object-manipulation]]

@@ -3750,7 +3750,7 @@ between the working tree, the index, and the object database. Git

3750 provides low-level operations which perform each of these steps

3751 individually.

3752

3753 -Generally, all "git" operations work on the index file. Some operations

3753 +Generally, all Git operations work on the index file. Some operations

3754 work *purely* on the index file (showing the current state of the

3755 index), but most operations move data between the index file and either

3756 the database or the working directory. Thus there are four main

@@ -3773,7 +3773,7 @@ but to avoid common mistakes with filename globbing etc, the command

3773 will not normally add totally new entries or remove old entries,

3774 i.e. it will normally just update existing cache entries.

3775

3776 -To tell git that yes, you really do realize that certain files no

3776 +To tell Git that yes, you really do realize that certain files no

3777 longer exist, or that new files should be added, you

3778 should use the `--remove` and `--add` flags respectively.

3779

@@ -3887,7 +3887,7 @@ redirection from a pipe or file, or by just typing it at the tty).

3887

3888 `git commit-tree` will return the name of the object that represents

3889 that commit, and you should save it away for later use. Normally,

3890 -you'd commit a new `HEAD` state, and while git doesn't care where you

3890 +you'd commit a new `HEAD` state, and while Git doesn't care where you

3891 save the note about that state, in practice we tend to just write the

3892 result to the file pointed at by `.git/HEAD`, so that we can always see

3893 what the last committed state was.

@@ -4044,7 +4044,7 @@ $ git ls-files --unmerged

4044

4045 Each line of the `git ls-files --unmerged` output begins with

4046 the blob mode bits, blob SHA-1, 'stage number', and the

4047 -filename. The 'stage number' is git's way to say which tree it

4047 +filename. The 'stage number' is Git's way to say which tree it

4048 came from: stage 1 corresponds to the `$orig` tree, stage 2 to

4049 the `HEAD` tree, and stage 3 to the `$target` tree.

4050

@@ -4056,7 +4056,7 @@ obviously the final outcome is what is in `HEAD`. What the

4056 above example shows is that file `hello.c` was changed from

4057 `$orig` to `HEAD` and `$orig` to `$target` in a different way.

4058 You could resolve this by running your favorite 3-way merge

4059 -program, e.g. `diff3`, `merge`, or git's own merge-file, on

4059 +program, e.g. `diff3`, `merge`, or Git's own merge-file, on

4060 the blob objects from these three stages yourself, like this:

4061

4062 ------------------------------------------------

@@ -4068,7 +4068,7 @@ $ git merge-file hello.c~2 hello.c~1 hello.c~3

4068

4069 This would leave the merge result in `hello.c~2` file, along

4070 with conflict markers if there are conflicts. After verifying

4071 -the merge result makes sense, you can tell git what the final

4071 +the merge result makes sense, you can tell Git what the final

4072 merge result for this file is by:

4073

4074 -------------------------------------------------

@@ -4077,11 +4077,11 @@ $ git update-index hello.c

4077 -------------------------------------------------

4078

4079 When a path is in the "unmerged" state, running `git update-index` for

4080 -that path tells git to mark the path resolved.

4080 +that path tells Git to mark the path resolved.

4081

4082 -The above is the description of a git merge at the lowest level,

4082 +The above is the description of a Git merge at the lowest level,

4083 to help you understand what conceptually happens under the hood.

4084 -In practice, nobody, not even git itself, runs `git cat-file` three times

4084 +In practice, nobody, not even Git itself, runs `git cat-file` three times

4085 for this. There is a `git merge-index` program that extracts the

4086 stages to temporary files and calls a "merge" script on it:

4087

@@ -4092,11 +4092,11 @@ $ git merge-index git-merge-one-file hello.c

4092 and that is what higher level `git merge -s resolve` is implemented with.

4093

4094 [[hacking-git]]

4095 -Hacking git

4095 +Hacking Git

4096 ===========

4097

4098 -This chapter covers internal details of the git implementation which

4099 -probably only git developers need to understand.

4098 +This chapter covers internal details of the Git implementation which

4099 +probably only Git developers need to understand.

4100

4101 [[object-details]]

4102 Object storage format

@@ -4114,7 +4114,7 @@ about the data in the object. It's worth noting that the SHA-1 hash

4114 that is used to name the object is the hash of the original data

4115 plus this header, so `sha1sum` 'file' does not match the object name

4116 for 'file'.

4117 -(Historical note: in the dawn of the age of git the hash

4117 +(Historical note: in the dawn of the age of Git the hash

4118 was the SHA-1 of the 'compressed' object.)

4119

4120 As a result, the general consistency of an object can always be tested

@@ -4144,7 +4144,7 @@ A good place to start is with the contents of the initial commit, with:

4144 $ git checkout e83c5163

4145 ----------------------------------------------------

4146

4147 -The initial revision lays the foundation for almost everything git has

4147 +The initial revision lays the foundation for almost everything Git has

4148 today, but is small enough to read in one sitting.

4149

4150 Note that terminology has changed since that revision. For example, the

@@ -4298,7 +4298,7 @@ Now, for the meat:

4298 This is how you read a blob (actually, not only a blob, but any type of

4299 object). To know how the function `read_object_with_reference()` actually

4300 works, find the source code for it (something like `git grep

4301 -read_object_with | grep ":[a-z]"` in the git repository), and read

4301 +read_object_with | grep ":[a-z]"` in the Git repository), and read

4302 the source.

4303

4304 To find out how the result can be used, just read on in `cmd_cat_file()`:

@@ -4479,7 +4479,7 @@ $ git bisect bad # if this revision is bad.

4479 Making changes

4480 --------------

4481

4482 -Make sure git knows who to blame:

4482 +Make sure Git knows who to blame:

4483

4484 ------------------------------------------------

4485 $ cat >>~/.gitconfig <<\EOF

@@ -4529,7 +4529,7 @@ $ git format-patch origin..HEAD # format a patch for each commit

4529 $ git am mbox # import patches from the mailbox "mbox"

4530 -----------------------------------------------

4531

4532 -Fetch a branch in a different git repository, then merge into the

4532 +Fetch a branch in a different Git repository, then merge into the

4533 current branch:

4534

4535 -----------------------------------------------

@@ -4590,7 +4590,7 @@ The basic requirements:

4590

4591 - It must be readable in order, from beginning to end, by someone

4592 intelligent with a basic grasp of the UNIX command line, but without

4593 - any special knowledge of git. If necessary, any other prerequisites

4593 + any special knowledge of Git. If necessary, any other prerequisites

4594 should be specifically mentioned as they arise.

4595 - Whenever possible, section headings should clearly describe the task

4596 they explain how to do, in language that requires no more knowledge