@matheusbsbs / matheus-bagliano / commits / 0b444cdb19

Fork 0

Documentation: spell 'git cmd' without dash throughout

The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.

Thomas Rast committed Jan 10, 2010 at 00:33 UTC 0b444cdb19bcfcc7f59b7b00783cbfbbc5ddcf63

112 files changed +647 -647

Documentation/config.txt

+36 -36

@@ -64,7 +64,7 @@ The values following the equals sign in variable assign are all either

64 a string, an integer, or a boolean. Boolean values may be given as yes/no,

65 0/1, true/false or on/off. Case is not significant in boolean values, when

66 converting value to the canonical form using '--bool' type specifier;

67 -'git-config' will ensure that the output is "true" or "false".

67 +'git config' will ensure that the output is "true" or "false".

69 String values may be entirely or partially enclosed in double quotes.

70 You need to enclose variable values in double quotes if you want to

@@ -442,8 +442,8 @@ core.pager::

442

443 core.whitespace::

444 A comma separated list of common whitespace problems to

445 - notice. 'git-diff' will use `color.diff.whitespace` to

446 - highlight them, and 'git-apply --whitespace=error' will

445 + notice. 'git diff' will use `color.diff.whitespace` to

446 + highlight them, and 'git apply --whitespace=error' will

447 consider them as errors. You can prefix `-` to disable

448 any of them (e.g. `-trailing-space`):

449 +

@@ -503,7 +503,7 @@ This setting defaults to "refs/notes/commits", and can be overridden by

503 the `GIT_NOTES_REF` environment variable.

504

505 add.ignore-errors::

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

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

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

508 option of linkgit:git-add[1].

509

@@ -525,19 +525,19 @@ executed from the top-level directory of a repository, which may

525 not necessarily be the current directory.

526

527 apply.ignorewhitespace::

528 - When set to 'change', tells 'git-apply' to ignore changes in

528 + When set to 'change', tells 'git apply' to ignore changes in

529 whitespace, in the same way as the '--ignore-space-change'

530 option.

531 - When set to one of: no, none, never, false tells 'git-apply' to

531 + When set to one of: no, none, never, false tells 'git apply' to

532 respect all whitespace differences.

533 See linkgit:git-apply[1].

534

535 apply.whitespace::

536 - Tells 'git-apply' how to handle whitespaces, in the same way

536 + Tells 'git apply' how to handle whitespaces, in the same way

537 as the '--whitespace' option. See linkgit:git-apply[1].

538

539 branch.autosetupmerge::

540 - Tells 'git-branch' and 'git-checkout' to setup new branches

540 + Tells 'git branch' and 'git checkout' to setup new branches

541 so that linkgit:git-pull[1] will appropriately merge from the

542 starting point branch. Note that even if this option is not set,

543 this behavior can be chosen per-branch using the `--track`

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

548 branch. This option defaults to true.

549

550 branch.autosetuprebase::

551 - When a new branch is created with 'git-branch' or 'git-checkout'

551 + When a new branch is created with 'git branch' or 'git checkout'

552 that tracks another branch, this variable tells git to set

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

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

@@ -563,24 +563,24 @@ branch.autosetuprebase::

563 This option defaults to never.

564

565 branch.<name>.remote::

566 - When in branch <name>, it tells 'git-fetch' and 'git-push' which

566 + When in branch <name>, it tells 'git fetch' and 'git push' which

567 remote to fetch from/push to. It defaults to `origin` if no remote is

568 configured. `origin` is also used if you are not on any branch.

569

570 branch.<name>.merge::

571 Defines, together with branch.<name>.remote, the upstream branch

572 - for the given branch. It tells 'git-fetch'/'git-pull' which

573 - branch to merge and can also affect 'git-push' (see push.default).

574 - When in branch <name>, it tells 'git-fetch' the default

572 + for the given branch. It tells 'git fetch'/'git pull' which

573 + branch to merge and can also affect 'git push' (see push.default).

574 + When in branch <name>, it tells 'git fetch' the default

575 refspec to be marked for merging in FETCH_HEAD. The value is

576 handled like the remote part of a refspec, and must match a

577 ref which is fetched from the remote given by

578 "branch.<name>.remote".

579 - The merge information is used by 'git-pull' (which at first calls

580 - 'git-fetch') to lookup the default branch for merging. Without

581 - this option, 'git-pull' defaults to merge the first refspec fetched.

579 + The merge information is used by 'git pull' (which at first calls

580 + 'git fetch') to lookup the default branch for merging. Without

581 + this option, 'git pull' defaults to merge the first refspec fetched.

582 Specify multiple values to get an octopus merge.

583 - If you wish to setup 'git-pull' so that it merges into <name> from

583 + If you wish to setup 'git pull' so that it merges into <name> from

584 another branch in the local repository, you can point

585 branch.<name>.merge to the desired branch, and use the special setting

586 `.` (a period) for branch.<name>.remote.

@@ -673,7 +673,7 @@ color.interactive::

673 colors only when the output is to the terminal. Defaults to false.

674

675 color.interactive.<slot>::

676 - Use customized color for 'git-add --interactive'

676 + Use customized color for 'git add --interactive'

677 output. `<slot>` may be `prompt`, `header`, `help` or `error`, for

678 four distinct types of normal output from interactive

679 commands. The values of these variables may be specified as

@@ -718,14 +718,14 @@ commit.template::

718 specified user's home directory.

719

720 diff.autorefreshindex::

721 - When using 'git-diff' to compare with work tree

721 + When using 'git diff' to compare with work tree

722 files, do not consider stat-only change as changed.

723 Instead, silently run `git update-index --refresh` to

724 update the cached stat information for paths whose

725 contents in the work tree match the contents in the

726 index. This option defaults to true. Note that this

727 - affects only 'git-diff' Porcelain, and not lower level

728 - 'diff' commands, such as 'git-diff-files'.

727 + affects only 'git diff' Porcelain, and not lower level

728 + 'diff' commands, such as 'git diff-files'.

729

730 diff.external::

731 If this config variable is set, diff generation is not

@@ -737,7 +737,7 @@ diff.external::

737 your files, you might want to use linkgit:gitattributes[5] instead.

738

739 diff.mnemonicprefix::

740 - If set, 'git-diff' uses a prefix pair that is different from the

740 + If set, 'git diff' uses a prefix pair that is different from the

741 standard "a/" and "b/" depending on what is being compared. When

742 this configuration is in effect, reverse diff output also swaps

743 the order of the prefixes:

@@ -754,7 +754,7 @@ diff.mnemonicprefix::

754

755 diff.renameLimit::

756 The number of files to consider when performing the copy/rename

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

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

758

759 diff.renames::

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

@@ -840,7 +840,7 @@ format.pretty::

840 linkgit:git-whatchanged[1].

841

842 format.thread::

843 - The default threading style for 'git-format-patch'. Can be

843 + The default threading style for 'git format-patch'. Can be

844 either a boolean value, `shallow` or `deep`. `shallow`

845 threading makes every mail a reply to the head of the series,

846 where the head is chosen from the cover letter, the

@@ -858,7 +858,7 @@ format.signoff::

858

859 gc.aggressiveWindow::

860 The window size parameter used in the delta compression

861 - algorithm used by 'git-gc --aggressive'. This defaults

861 + algorithm used by 'git gc --aggressive'. This defaults

862 to 10.

863

864 gc.auto::

@@ -875,39 +875,39 @@ gc.autopacklimit::

875 default value is 50. Setting this to 0 disables it.

876

877 gc.packrefs::

878 - 'git-gc' does not run `git pack-refs` in a bare repository by

878 + 'git gc' does not run `git pack-refs` in a bare repository by

879 default so that older dumb-transport clients can still fetch

880 - from the repository. Setting this to `true` lets 'git-gc'

880 + from the repository. Setting this to `true` lets 'git gc'

881 to run `git pack-refs`. Setting this to `false` tells

882 - 'git-gc' never to run `git pack-refs`. The default setting is

882 + 'git gc' never to run `git pack-refs`. The default setting is

883 `notbare`. Enable it only when you know you do not have to

884 support such clients. The default setting will change to `true`

885 at some stage, and setting this to `false` will continue to

886 - prevent `git pack-refs` from being run from 'git-gc'.

886 + prevent `git pack-refs` from being run from 'git gc'.

887

888 gc.pruneexpire::

889 - When 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'.

889 + When 'git gc' is run, it will call 'prune --expire 2.weeks.ago'.

890 Override the grace period with this config variable. The value

891 "now" may be used to disable this grace period and always prune

892 unreachable objects immediately.

893

894 gc.reflogexpire::

895 - 'git-reflog expire' removes reflog entries older than

895 + 'git reflog expire' removes reflog entries older than

896 this time; defaults to 90 days.

897

898 gc.reflogexpireunreachable::

899 - 'git-reflog expire' removes reflog entries older than

899 + 'git reflog expire' removes reflog entries older than

900 this time and are not reachable from the current tip;

901 defaults to 30 days.

902

903 gc.rerereresolved::

904 Records of conflicted merge you resolved earlier are

905 - kept for this many days when 'git-rerere gc' is run.

905 + kept for this many days when 'git rerere gc' is run.

906 The default is 60 days. See linkgit:git-rerere[1].

907

908 gc.rerereunresolved::

909 Records of conflicted merge you have not resolved are

910 - kept for this many days when 'git-rerere gc' is run.

910 + kept for this many days when 'git rerere gc' is run.

911 The default is 15 days. See linkgit:git-rerere[1].

912

913 gitcvs.commitmsgannotation::

@@ -1168,7 +1168,7 @@ i18n.commitEncoding::

1168

1169 i18n.logOutputEncoding::

1170 Character encoding the commit messages are converted to when

1171 - running 'git-log' and friends.

1171 + running 'git log' and friends.

1172

1173 imap::

1174 The configuration variables in the 'imap' section are described

@@ -1202,7 +1202,7 @@ interactive.singlekey::

1202

1203 log.date::

1204 Set default date-time mode for the log command. Setting log.date

1205 - value is similar to using 'git-log'\'s --date option. The value is one of the

1205 + value is similar to using 'git log'\'s --date option. The value is one of the

1206 following alternatives: {relative,local,default,iso,rfc,short}.

1207 See linkgit:git-log[1].

1208

Documentation/fetch-options.txt

+5 -5

@@ -19,7 +19,7 @@ endif::git-pull[]

20 -f::

21 --force::

22 - When 'git-fetch' is used with `<rbranch>:<lbranch>`

22 + When 'git fetch' is used with `<rbranch>:<lbranch>`

23 refspec, it refuses to update the local branch

24 `<lbranch>` unless the remote branch `<rbranch>` it

25 fetches is a descendant of `<lbranch>`. This option

@@ -61,16 +61,16 @@ endif::git-pull[]

62 -u::

63 --update-head-ok::

64 - By default 'git-fetch' refuses to update the head which

64 + By default 'git fetch' refuses to update the head which

65 corresponds to the current branch. This flag disables the

66 - check. This is purely for the internal use for 'git-pull'

67 - to communicate with 'git-fetch', and unless you are

66 + check. This is purely for the internal use for 'git pull'

67 + to communicate with 'git fetch', and unless you are

68 implementing your own Porcelain you are not supposed to

69 use it.

71 --upload-pack <upload-pack>::

72 When given, and the repository to fetch from is handled

73 - by 'git-fetch-pack', '--exec=<upload-pack>' is passed to

73 + by 'git fetch-pack', '--exec=<upload-pack>' is passed to

74 the command to specify non-default path for the command

75 run on the other end.

Documentation/git-am.txt

+5 -5

@@ -37,7 +37,7 @@ OPTIONS

38 -k::

39 --keep::

40 - Pass `-k` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).

40 + Pass `-k` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).

42 -c::

43 --scissors::

@@ -53,7 +53,7 @@ OPTIONS

54 -u::

55 --utf8::

56 - Pass `-u` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).

56 + Pass `-u` flag to 'git mailinfo' (see linkgit:git-mailinfo[1]).

57 The proposed commit log message taken from the e-mail

58 is re-coded into UTF-8 encoding (configuration variable

59 `i18n.commitencoding` can be used to specify project's

@@ -63,7 +63,7 @@ This was optional in prior versions of git, but now it is the

63 default. You can use `--no-utf8` to override this.

65 --no-utf8::

66 - Pass `-n` flag to 'git-mailinfo' (see

66 + Pass `-n` flag to 'git mailinfo' (see

67 linkgit:git-mailinfo[1]).

69 -3::

@@ -81,7 +81,7 @@ default. You can use `--no-utf8` to override this.

81 -p<n>::

82 --directory=<dir>::

83 --reject::

84 - These flags are passed to the 'git-apply' (see linkgit:git-apply[1])

84 + These flags are passed to the 'git apply' (see linkgit:git-apply[1])

85 program that applies

86 the patch.

@@ -121,7 +121,7 @@ default. You can use `--no-utf8` to override this.

121 to the screen before exiting. This overrides the

122 standard message informing you to use `--resolved`

123 or `--skip` to handle the failure. This is solely

124 - for internal use between 'git-rebase' and 'git-am'.

124 + for internal use between 'git rebase' and 'git am'.

125

126 --abort::

127 Restore the original branch and abort the patching operation.

Documentation/git-apply.txt

+5 -5

@@ -69,7 +69,7 @@ OPTIONS

69 without using the working tree. This implies `--index`.

71 --build-fake-ancestor=<file>::

72 - Newer 'git-diff' output has embedded 'index information'

72 + Newer 'git diff' output has embedded 'index information'

73 for each blob to help identify the original version that

74 the patch applies to. When this flag is given, and if

75 the original versions of the blobs are available locally,

@@ -83,7 +83,7 @@ the information is read from the current index instead.

83 Apply the patch in reverse.

85 --reject::

86 - For atomicity, 'git-apply' by default fails the whole patch and

86 + For atomicity, 'git apply' by default fails the whole patch and

87 does not touch the working tree when some of the hunks

88 do not apply. This option makes it apply

89 the parts of the patch that are applicable, and leave the

@@ -109,7 +109,7 @@ any of those replacements occurred.

109 ever ignored.

110

111 --unidiff-zero::

112 - By default, 'git-apply' expects that the patch being

112 + By default, 'git apply' expects that the patch being

113 applied is a unified diff with at least one line of context.

114 This provides good safety measures, but breaks down when

115 applying a diff generated with `--unified=0`. To bypass these

@@ -120,7 +120,7 @@ discouraged.

120

121 --apply::

122 If you use any of the options marked "Turns off

123 - 'apply'" above, 'git-apply' reads and outputs the

123 + 'apply'" above, 'git apply' reads and outputs the

124 requested information without actually applying the

125 patch. Give this flag after those flags to also apply

126 the patch.

@@ -229,7 +229,7 @@ apply.whitespace::

229

230 Submodules

231 ----------

232 -If the patch contains any changes to submodules then 'git-apply'

232 +If the patch contains any changes to submodules then 'git apply'

233 treats these changes as follows.

234

235 If `--index` is specified (explicitly or implicitly), then the submodule

Documentation/git-archimport.txt

+6 -6

@@ -29,17 +29,17 @@ branches that have different roots, it will refuse to run. In that case,

29 edit your <archive/branch> parameters to define clearly the scope of the

30 import.

32 -'git-archimport' uses `tla` extensively in the background to access the

32 +'git archimport' uses `tla` extensively in the background to access the

33 Arch repository.

34 Make sure you have a recent version of `tla` available in the path. `tla` must

35 -know about the repositories you pass to 'git-archimport'.

35 +know about the repositories you pass to 'git archimport'.

37 -For the initial import, 'git-archimport' expects to find itself in an empty

37 +For the initial import, 'git archimport' expects to find itself in an empty

38 directory. To follow the development of a project that uses Arch, rerun

39 -'git-archimport' with the same parameters as the initial import to perform

39 +'git archimport' with the same parameters as the initial import to perform

40 incremental imports.

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

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>

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

@@ -84,7 +84,7 @@ OPTIONS

85 -o::

86 Use this for compatibility with old-style branch names used by

87 - earlier versions of 'git-archimport'. Old-style branch names

87 + earlier versions of 'git archimport'. Old-style branch names

88 were category--branch, whereas new-style branch names are

89 archive,category--branch--version. In both cases, names given

90 on the command-line will override the automatically-generated

Documentation/git-archive.txt

+2 -2

@@ -21,13 +21,13 @@ structure for the named tree, and writes it out to the standard

21 output. If <prefix> is specified it is

22 prepended to the filenames in the archive.

24 -'git-archive' behaves differently when given a tree ID versus when

24 +'git archive' behaves differently when given a tree ID versus when

25 given a commit ID or tag ID. In the first case the current time is

26 used as the modification time of each file in the archive. In the latter

27 case the commit time as recorded in the referenced commit object is

28 used instead. Additionally the commit ID is stored in a global

29 extended pax header if the tar format is used; it can be extracted

30 -using 'git-get-tar-commit-id'. In ZIP files it is stored as a file

30 +using 'git get-tar-commit-id'. In ZIP files it is stored as a file

31 comment.

33 OPTIONS

Documentation/git-blame.txt

+4 -4

@@ -21,7 +21,7 @@ last modified the line. Optionally, start annotating from the given revision.

21 The command can also limit the range of lines annotated.

23 The report does not tell you anything about lines which have been deleted or

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

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

25 interface briefly mentioned in the following paragraph.

27 Apart from supporting file annotation, git also supports searching the

@@ -49,7 +49,7 @@ include::blame-options.txt[]

49 file (see `-M`). The first number listed is the score.

50 This is the number of alphanumeric characters detected

51 as having been moved between or within files. This must be above

52 - a certain threshold for 'git-blame' to consider those lines

52 + a certain threshold for 'git blame' to consider those lines

53 of code to have been moved.

55 -f::

@@ -100,7 +100,7 @@ header elements later.

100 SPECIFYING RANGES

101 -----------------

102

103 -Unlike 'git-blame' and 'git-annotate' in older versions of git, the extent

103 +Unlike 'git blame' and 'git annotate' in older versions of git, the extent

104 of the annotation can be limited to both line ranges and revision

105 ranges. When you are interested in finding the origin for

106 lines 40-60 for file `foo`, you can use the `-L` option like so

@@ -118,7 +118,7 @@ which limits the annotation to the body of the `hello` subroutine.

118

119 When you are not interested in changes older than version

120 v2.6.18, or changes older than 3 weeks, you can use revision

121 -range specifiers similar to 'git-rev-list':

121 +range specifiers similar to 'git rev-list':

122

123 git blame v2.6.18.. -- foo

124 git blame --since=3.weeks -- foo

Documentation/git-branch.txt

+3 -3

@@ -38,7 +38,7 @@ working tree to it; use "git checkout <newbranch>" to switch to the

38 new branch.

40 When a local branch is started off a remote branch, git sets up the

41 -branch so that 'git-pull' will appropriately merge from

41 +branch so that 'git pull' will appropriately merge from

42 the remote branch. This behavior may be changed via the global

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

44 overridden by using the `--track` and `--no-track` options.

@@ -55,7 +55,7 @@ has a reflog then the reflog will also be deleted.

56 Use -r together with -d to delete remote-tracking branches. Note, that it

57 only makes sense to delete remote-tracking branches if they no longer exist

58 -in the remote repository or if 'git-fetch' was configured not to fetch

58 +in the remote repository or if 'git fetch' was configured not to fetch

59 them again. See also the 'prune' subcommand of linkgit:git-remote[1] for a

60 way to clean up all obsolete remote-tracking branches.

@@ -76,7 +76,7 @@ OPTIONS

76 -f::

77 --force::

78 Reset <branchname> to <startpoint> if <branchname> exists

79 - already. Without `-f` 'git-branch' refuses to change an existing branch.

79 + already. Without `-f` 'git branch' refuses to change an existing branch.

81 -m::

82 Move/rename a branch and the corresponding reflog.

Documentation/git-bundle.txt

+13 -13

@@ -21,9 +21,9 @@ 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,

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

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

26 -another repository using 'git-fetch' and 'git-pull'

26 +another repository using 'git fetch' and 'git pull'

27 after moving the archive by some means (e.g., by sneakernet). As no

28 direct connection between the repositories exists, the user must specify a

29 basis for the bundle that is held by the destination repository: the

@@ -35,14 +35,14 @@ OPTIONS

36 create <file>::

37 Used to create a bundle named 'file'. This requires the

38 - 'git-rev-list' arguments to define the bundle contents.

38 + 'git rev-list' arguments to define the bundle contents.

40 verify <file>::

41 Used to check that a bundle file is valid and will apply

42 cleanly to the current repository. This includes checks on the

43 bundle format itself as well as checking that the prerequisite

44 commits exist and are fully linked in the current repository.

45 - 'git-bundle' prints a list of missing commits, if any, and exits

45 + 'git bundle' prints a list of missing commits, if any, and exits

46 with a non-zero status.

48 list-heads <file>::

@@ -51,15 +51,15 @@ list-heads <file>::

51 printed out.

53 unbundle <file>::

54 - Passes the objects in the bundle to 'git-index-pack'

54 + Passes the objects in the bundle to 'git index-pack'

55 for storage in the repository, then prints the names of all

56 defined references. If a list of references is given, only

57 references matching those in the list are printed. This command is

58 - really plumbing, intended to be called only by 'git-fetch'.

58 + really plumbing, intended to be called only by 'git fetch'.

60 [git-rev-list-args...]::

61 - A list of arguments, acceptable to 'git-rev-parse' and

62 - 'git-rev-list', that specifies the specific objects and references

61 + A list of arguments, acceptable to 'git rev-parse' and

62 + 'git rev-list', that specifies the specific objects and references

63 to transport. For example, `master\~10..master` causes the

64 current master reference to be packaged along with all objects

65 added since its 10th ancestor commit. There is no explicit

@@ -69,16 +69,16 @@ unbundle <file>::

70 [refname...]::

71 A list of references used to limit the references reported as

72 - available. This is principally of use to 'git-fetch', which

72 + available. This is principally of use to 'git fetch', which

73 expects to receive only those references asked for and not

74 - necessarily everything in the pack (in this case, 'git-bundle' acts

75 - like 'git-fetch-pack').

74 + necessarily everything in the pack (in this case, 'git bundle' acts

75 + like 'git fetch-pack').

77 SPECIFYING REFERENCES

78 ---------------------

80 -'git-bundle' will only package references that are shown by

81 -'git-show-ref': this includes heads, tags, and remote heads. References

80 +'git bundle' will only package references that are shown by

81 +'git show-ref': this includes heads, tags, and remote heads. References

82 such as `master\~1` cannot be packaged, but are perfectly suitable for

83 defining the basis. More than one reference may be packaged, and more

84 than one basis can be specified. The objects packaged are those not

Documentation/git-check-ref-format.txt

+1 -1

@@ -60,7 +60,7 @@ reference name expressions (see linkgit:git-rev-parse[1]):

60 . A colon `:` is used as in `srcref:dstref` to mean "use srcref\'s

61 value and store it in dstref" in fetch and push operations.

62 It may also be used to select a specific object such as with

63 - 'git-cat-file': "git cat-file blob v1.3.3:refs.c".

63 + 'git cat-file': "git cat-file blob v1.3.3:refs.c".

65 . at-open-brace `@{` is used as a notation to access a reflog entry.

Documentation/git-checkout-index.txt

+4 -4

@@ -88,7 +88,7 @@ $ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --

88 which will force all existing `*.h` files to be replaced with their

89 cached copies. If an empty command line implied "all", then this would

90 force-refresh everything in the index, which was not the point. But

91 -since 'git-checkout-index' accepts --stdin it would be faster to use:

91 +since 'git checkout-index' accepts --stdin it would be faster to use:

93 ----------------

94 $ find . -name '*.h' -print0 | git checkout-index -f -z --stdin

@@ -102,7 +102,7 @@ Using `--` is probably a good policy in scripts.

102 Using --temp or --stage=all

103 ---------------------------

104 When `--temp` is used (or implied by `--stage=all`)

105 -'git-checkout-index' will create a temporary file for each index

105 +'git checkout-index' will create a temporary file for each index

106 entry being checked out. The index will not be updated with stat

107 information. These options can be useful if the caller needs all

108 stages of all unmerged entries so that the unmerged files can be

@@ -147,9 +147,9 @@ To update and refresh only the files already checked out::

147 $ git checkout-index -n -f -a && git update-index --ignore-missing --refresh

148 ----------------

149

150 -Using 'git-checkout-index' to "export an entire tree"::

150 +Using 'git checkout-index' to "export an entire tree"::

151 The prefix ability basically makes it trivial to use

152 - 'git-checkout-index' as an "export as tree" function.

152 + 'git checkout-index' as an "export as tree" function.

153 Just read the desired tree into the index, and do:

154 +

155 ----------------

Documentation/git-cherry-pick.txt

+1 -1

@@ -24,7 +24,7 @@ OPTIONS

25 -e::

26 --edit::

27 - With this option, 'git-cherry-pick' will let you edit the commit

27 + With this option, 'git cherry-pick' will let you edit the commit

28 message prior to committing.

30 -x::

Documentation/git-cherry.txt

+3 -3

@@ -14,7 +14,7 @@ DESCRIPTION

14 The changeset (or "diff") of each commit between the fork-point and <head>

15 is compared against each commit between the fork-point and <upstream>.

16 The commits are compared with their 'patch id', obtained from

17 -the 'git-patch-id' program.

17 +the 'git patch-id' program.

19 Every commit that doesn't exist in the <upstream> branch

20 has its id (sha1) reported, prefixed by a symbol. The ones that have

@@ -37,8 +37,8 @@ to and including <limit> are not reported:

37 \__*__*__<limit>__-__+__> <head>

40 -Because 'git-cherry' compares the changeset rather than the commit id

41 -(sha1), you can use 'git-cherry' to find out if a commit you made locally

40 +Because 'git cherry' compares the changeset rather than the commit id

41 +(sha1), you can use 'git cherry' to find out if a commit you made locally

42 has been applied <upstream> under a different commit id. For example,

43 this will happen if you're feeding patches <upstream> via email rather

44 than pushing or pulling commits directly.

Documentation/git-citool.txt

+2 -2

@@ -14,9 +14,9 @@ DESCRIPTION

14 A Tcl/Tk based graphical interface to review modified files, stage

15 them into the index, enter a commit message and record the new

16 commit onto the current branch. This interface is an alternative

17 -to the less interactive 'git-commit' program.

17 +to the less interactive 'git commit' program.

19 -'git-citool' is actually a standard alias for `git gui citool`.

19 +'git citool' is actually a standard alias for `git gui citool`.

20 See linkgit:git-gui[1] for more details.

22 Author

Documentation/git-clean.txt

+2 -2

@@ -34,7 +34,7 @@ OPTIONS

34 -f::

35 --force::

36 If the git configuration specifies clean.requireForce as true,

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

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

39 -n::

40 --dry-run::

@@ -48,7 +48,7 @@ OPTIONS

48 -x::

49 Don't use the ignore rules. This allows removing all untracked

50 files, including build products. This can be used (possibly in

51 - conjunction with 'git-reset') to create a pristine

51 + conjunction with 'git reset') to create a pristine

52 working directory to test a clean build.

54 -X::

Documentation/git-commit-tree.txt

+1 -1

@@ -70,7 +70,7 @@ is taken from the configuration items user.name and user.email, or, if not

70 present, system user name and fully qualified hostname.

72 A commit comment is read from stdin. If a changelog

73 -entry is not provided via "<" redirection, 'git-commit-tree' will just wait

73 +entry is not provided via "<" redirection, 'git commit-tree' will just wait

74 for one to be entered and terminated with ^D.

76 include::date-formats.txt[]

Documentation/git-commit.txt

+10 -10

@@ -20,11 +20,11 @@ with a log message from the user describing the changes.

21 The content to be added can be specified in several ways:

23 -1. by using 'git-add' to incrementally "add" changes to the

23 +1. by using 'git add' to incrementally "add" changes to the

24 index before using the 'commit' command (Note: even modified

25 files must be "added");

27 -2. by using 'git-rm' to remove files from the working tree

27 +2. by using 'git rm' to remove files from the working tree

28 and the index, again before using the 'commit' command;

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

@@ -40,14 +40,14 @@ The content to be added can be specified in several ways:

41 5. by using the --interactive switch with the 'commit' command to decide one

42 by one which files should be part of the commit, before finalizing the

43 - operation. Currently, this is done by invoking 'git-add --interactive'.

43 + operation. Currently, this is done by invoking 'git add --interactive'.

45 The `--dry-run` option can be used to obtain a

46 summary of what is included by any of the above for the next

47 commit by giving the same set of parameters (options and paths).

49 If you make a commit and then find a mistake immediately after

50 -that, you can recover from it with 'git-reset'.

50 +that, you can recover from it with 'git reset'.

53 OPTIONS

@@ -184,7 +184,7 @@ FROM UPSTREAM REBASE" section in linkgit:git-rebase[1].)

184 Make a commit only from the paths specified on the

185 command line, disregarding any contents that have been

186 staged so far. This is the default mode of operation of

187 - 'git-commit' if any paths are given on the command line,

187 + 'git commit' if any paths are given on the command line,

188 in which case this option can be omitted.

189 If this option is specified together with '--amend', then

190 no paths need to be specified, which can be used to amend

@@ -241,10 +241,10 @@ EXAMPLES

241 --------

242 When recording your own work, the contents of modified files in

243 your working tree are temporarily stored to a staging area

244 -called the "index" with 'git-add'. A file can be

244 +called the "index" with 'git add'. A file can be

245 reverted back, only in the index but not in the working tree,

246 to that of the last commit with `git reset HEAD -- <file>`,

247 -which effectively reverts 'git-add' and prevents the changes to

247 +which effectively reverts 'git add' and prevents the changes to

248 this file from participating in the next commit. After building

249 the state to be committed incrementally with these commands,

250 `git commit` (without any pathname parameter) is used to record what

@@ -300,13 +300,13 @@ $ git commit

300 this second commit would record the changes to `hello.c` and

301 `hello.h` as expected.

302

303 -After a merge (initiated by 'git-merge' or 'git-pull') stops

303 +After a merge (initiated by 'git merge' or 'git pull') stops

304 because of conflicts, cleanly merged

305 paths are already staged to be committed for you, and paths that

306 conflicted are left in unmerged state. You would have to first

307 -check which paths are conflicting with 'git-status'

307 +check which paths are conflicting with 'git status'

308 and after fixing them manually in your working tree, you would

309 -stage the result as usual with 'git-add':

309 +stage the result as usual with 'git add':

310

311 ------------

312 $ git status | grep unmerged

Documentation/git-config.txt

+7 -7

@@ -38,7 +38,7 @@ you want to handle the lines that do *not* match the regex, just

38 prepend a single exclamation mark in front (see also <<EXAMPLES>>).

40 The type specifier can be either '--int' or '--bool', which will make

41 -'git-config' ensure that the variable(s) are of the given type and

41 +'git config' ensure that the variable(s) are of the given type and

42 convert the value to the canonical form (simple decimal number for int,

43 a "true" or "false" string for bool). If no type specifier is passed,

44 no checks or transformations are performed on the value.

@@ -124,16 +124,16 @@ See also <<FILES>>.

124 List all variables set in config file.

125

126 --bool::

127 - 'git-config' will ensure that the output is "true" or "false"

127 + 'git config' will ensure that the output is "true" or "false"

128

129 --int::

130 - 'git-config' will ensure that the output is a simple

130 + 'git config' will ensure that the output is a simple

131 decimal number. An optional value suffix of 'k', 'm', or 'g'

132 in the config file will cause the value to be multiplied

133 by 1024, 1048576, or 1073741824 prior to output.

134

135 --bool-or-int::

136 - 'git-config' will ensure that the output matches the format of

136 + 'git config' will ensure that the output matches the format of

137 either --bool or --int, as described above.

138

139 -z::

@@ -173,7 +173,7 @@ FILES

173 -----

174

175 If not set explicitly with '--file', there are three files where

176 -'git-config' will search for configuration options:

176 +'git config' will search for configuration options:

177

178 $GIT_DIR/config::

179 Repository specific configuration file. (The filename is

@@ -190,12 +190,12 @@ $(prefix)/etc/gitconfig::

190 If no further options are given, all reading options will read all of these

191 files that are available. If the global or the system-wide configuration

192 file are not available they will be ignored. If the repository configuration

193 -file is not available or readable, 'git-config' will exit with a non-zero

193 +file is not available or readable, 'git config' will exit with a non-zero

194 error code. However, in neither case will an error message be issued.

195

196 All writing options will per default write to the repository specific

197 configuration file. Note that this also affects options like '--replace-all'

198 -and '--unset'. *'git-config' will only ever change one file at a time*.

198 +and '--unset'. *'git config' will only ever change one file at a time*.

199

200 You can override these rules either by command line options or by environment

201 variables. The '--global' and the '--system' options will limit the file used

Documentation/git-cvsexportcommit.txt

+1 -1

@@ -27,7 +27,7 @@ by default.

28 Supports file additions, removals, and commits that affect binary files.

30 -If the commit is a merge commit, you must tell 'git-cvsexportcommit' what

30 +If the commit is a merge commit, you must tell 'git cvsexportcommit' what

31 parent the changeset should be done against.

33 OPTIONS

Documentation/git-cvsimport.txt

+9 -9

@@ -28,9 +28,9 @@ At least version 2.1 is required.

28 Please see the section <<issues,ISSUES>> for further reference.

30 You should *never* do any work of your own on the branches that are

31 -created by 'git-cvsimport'. By default initial import will create and populate a

31 +created by 'git cvsimport'. By default initial import will create and populate a

32 "master" branch from the CVS repository's main branch which you're free

33 -to work with; after that, you need to 'git-merge' incremental imports, or

33 +to work with; after that, you need to 'git merge' incremental imports, or

34 any CVS branches, yourself. It is advisable to specify a named remote via

35 -r to separate and protect the incoming branches.

@@ -49,13 +49,13 @@ OPTIONS

49 -d <CVSROOT>::

50 The root of the CVS archive. May be local (a simple path) or remote;

51 currently, only the :local:, :ext: and :pserver: access methods

52 - are supported. If not given, 'git-cvsimport' will try to read it

52 + are supported. If not given, 'git cvsimport' will try to read it

53 from `CVS/Root`. If no such file exists, it checks for the

54 `CVSROOT` environment variable.

56 <CVS_module>::

57 The CVS module you want to import. Relative to <CVSROOT>.

58 - If not given, 'git-cvsimport' tries to read it from

58 + If not given, 'git cvsimport' tries to read it from

59 `CVS/Repository`.

61 -C <target-dir>::

@@ -65,14 +65,14 @@ OPTIONS

65 -r <remote>::

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.

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.

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

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

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

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

77 branch.

78 +

@@ -145,17 +145,17 @@ This option can be used several times to provide several detection regexes.

145

146 ---------

147 +

148 -'git-cvsimport' will make it appear as those authors had

148 +'git cvsimport' will make it appear as those authors had

149 their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly

150 all along.

151 +

152 For convenience, this data is saved to `$GIT_DIR/cvs-authors`

153 each time the '-A' option is provided and read from that same

154 -file each time 'git-cvsimport' is run.

154 +file each time 'git cvsimport' is run.

155 +

156 It is not recommended to use this feature if you intend to

157 export changes back to CVS again later with

158 -'git-cvsexportcommit'.

158 +'git cvsexportcommit'.

159

160 -h::

161 Print a short usage message and exit.

Documentation/git-cvsserver.txt

+2 -2

@@ -22,7 +22,7 @@ cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver

22 Usage:

24 [verse]

25 -'git cvsserver' [options] [pserver|server] [<directory> ...]

25 +'git-cvsserver' [options] [pserver|server] [<directory> ...]

27 OPTIONS

28 -------

@@ -206,7 +206,7 @@ them write access to the directory, too.

206 The database can not be reliably regenerated in a

207 consistent form after the branch it is tracking has changed.

208 Example: For merged branches, 'git-cvsserver' only tracks

209 -one branch of development, and after a 'git-merge' an

209 +one branch of development, and after a 'git merge' an

210 incrementally updated database may track a different branch

211 than a database regenerated from scratch, causing inconsistent

212 CVS revision numbers. `git-cvsserver` has no way of knowing which

Documentation/git-daemon.txt

+21 -21

@@ -28,36 +28,36 @@ that service if it is enabled.

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

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

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

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

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

32 the offers to a whitelist comprising of those.

34 By default, only `upload-pack` service is enabled, which serves

35 -'git-fetch-pack' and 'git-ls-remote' clients, which are invoked

36 -from 'git-fetch', 'git-pull', and 'git-clone'.

35 +'git fetch-pack' and 'git ls-remote' clients, which are invoked

36 +from 'git fetch', 'git pull', and 'git clone'.

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

39 git repositories.

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

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

43 OPTIONS

44 -------

45 --strict-paths::

46 Match paths exactly (i.e. don't allow "/foo/repo" when the real path is

47 "/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.

48 - 'git-daemon' will refuse to start when this option is enabled and no

48 + 'git daemon' will refuse to start when this option is enabled and no

49 whitelist is specified.

51 --base-path=path::

52 Remap all the path requests as relative to the given path.

53 - This is sort of "GIT root" - if you run 'git-daemon' with

53 + This is sort of "GIT root" - if you run 'git daemon' with

54 '--base-path=/srv/git' on example.com, then if you later try to pull

55 - 'git://example.com/hello.git', 'git-daemon' will interpret the path

55 + 'git://example.com/hello.git', 'git daemon' will interpret the path

56 as '/srv/git/hello.git'.

58 --base-path-relaxed::

59 If --base-path is enabled and repo lookup fails, with this option

60 - 'git-daemon' will attempt to lookup without prefixing the base path.

60 + 'git daemon' will attempt to lookup without prefixing the base path.

61 This is useful for switching to --base-path usage, while still

62 allowing the old paths.

@@ -143,7 +143,7 @@ OPTIONS

143 +

144 Giving these options is an error when used with `--inetd`; use

145 the facility of inet daemon to achieve the same before spawning

146 -'git-daemon' if needed.

146 +'git daemon' if needed.

147

148 --enable=service::

149 --disable=service::

@@ -169,24 +169,24 @@ SERVICES

169

170 These services can be globally enabled/disabled using the

171 command line options of this command. If a finer-grained

172 -control is desired (e.g. to allow 'git-archive' to be run

172 +control is desired (e.g. to allow 'git archive' to be run

173 against only in a few selected repositories the daemon serves),

174 the per-repository configuration file can be used to enable or

175 disable them.

176

177 upload-pack::

178 - This serves 'git-fetch-pack' and 'git-ls-remote'

178 + This serves 'git fetch-pack' and 'git ls-remote'

179 clients. It is enabled by default, but a repository can

180 disable it by setting `daemon.uploadpack` configuration

181 item to `false`.

182

183 upload-archive::

184 - This serves 'git-archive --remote'. It is disabled by

184 + This serves 'git archive --remote'. It is disabled by

185 default, but a repository can enable it by setting

186 `daemon.uploadarch` configuration item to `true`.

187

188 receive-pack::

189 - This serves 'git-send-pack' clients, allowing anonymous

189 + This serves 'git send-pack' clients, allowing anonymous

190 push. It is disabled by default, as there is _no_

191 authentication in the protocol (in other words, anybody

192 can push anything into the repository, including removal

@@ -204,8 +204,8 @@ $ grep 9418 /etc/services

204 git 9418/tcp # Git Version Control System

205 ------------

206

207 -'git-daemon' as inetd server::

208 - To set up 'git-daemon' as an inetd service that handles any

207 +'git daemon' as inetd server::

208 + To set up 'git daemon' as an inetd service that handles any

209 repository under the whitelisted set of directories, /pub/foo

210 and /pub/bar, place an entry like the following into

211 /etc/inetd all on one line:

@@ -217,8 +217,8 @@ git 9418/tcp # Git Version Control System

217 ------------------------------------------------

218

219

220 -'git-daemon' as inetd server for virtual hosts::

221 - To set up 'git-daemon' as an inetd service that handles

220 +'git daemon' as inetd server for virtual hosts::

221 + To set up 'git daemon' as an inetd service that handles

222 repositories for different virtual hosts, `www.example.com`

223 and `www.example.org`, place an entry like the following into

224 `/etc/inetd` all on one line:

@@ -240,8 +240,8 @@ clients, a symlink from `/software` into the appropriate

240 default repository could be made as well.

241

242

243 -'git-daemon' as regular daemon for virtual hosts::

244 - To set up 'git-daemon' as a regular, non-inetd service that

243 +'git daemon' as regular daemon for virtual hosts::

244 + To set up 'git daemon' as a regular, non-inetd service that

245 handles repositories for multiple virtual hosts based on

246 their IP addresses, start the daemon like this:

247 +

@@ -258,7 +258,7 @@ Repositories can still be accessed by hostname though, assuming

258 they correspond to these IP addresses.

259

260 selectively enable/disable services per repository::

261 - To enable 'git-archive --remote' and disable 'git-fetch' against

261 + To enable 'git archive --remote' and disable 'git fetch' against

262 a repository, have the following in the configuration file in the

263 repository (that is the file 'config' next to 'HEAD', 'refs' and

264 'objects').

@@ -272,7 +272,7 @@ selectively enable/disable services per repository::

272

273 ENVIRONMENT

274 -----------

275 -'git-daemon' will set REMOTE_ADDR to the IP address of the client

275 +'git daemon' will set REMOTE_ADDR to the IP address of the client

276 that connected to it, if the IP address is available. REMOTE_ADDR will

277 be available in the environment of hooks called when

278 services are performed.

Documentation/git-describe.txt

+3 -3

@@ -106,7 +106,7 @@ of commits which would be displayed by "git log v1.0.4..parent".

106 The hash suffix is "-g" + 7-char abbreviation for the tip commit

107 of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).

108

109 -Doing a 'git-describe' on a tag-name will just show the tag name:

109 +Doing a 'git describe' on a tag-name will just show the tag name:

110

111 [torvalds@g5 git]$ git describe v1.0.4

112 v1.0.4

@@ -136,13 +136,13 @@ be sufficient to disambiguate these commits.

136 SEARCH STRATEGY

137 ---------------

138

139 -For each committish supplied, 'git-describe' will first look for

139 +For each committish supplied, 'git describe' will first look for

140 a tag which tags exactly that commit. Annotated tags will always

141 be preferred over lightweight tags, and tags with newer dates will

142 always be preferred over tags with older dates. If an exact match

143 is found, its name will be output and searching will stop.

144

145 -If an exact match was not found, 'git-describe' will walk back

145 +If an exact match was not found, 'git describe' will walk back

146 through the commit history to locate an ancestor commit which

147 has been tagged. The ancestor's tag will be output along with an

148 abbreviation of the input committish's SHA1.

Documentation/git-diff-files.txt

+1 -1

@@ -15,7 +15,7 @@ DESCRIPTION

15 Compares the files in the working tree and the index. When paths

16 are specified, compares only those named paths. Otherwise all

17 entries in the index are compared. The output format is the

18 -same as for 'git-diff-index' and 'git-diff-tree'.

18 +same as for 'git diff-index' and 'git diff-tree'.

20 OPTIONS

21 -------

Documentation/git-diff-index.txt

+10 -10

@@ -31,7 +31,7 @@ include::diff-options.txt[]

31 -m::

32 By default, files recorded in the index but not checked

33 out are reported as deleted. This flag makes

34 - 'git-diff-index' say that all non-checked-out files are up

34 + 'git diff-index' say that all non-checked-out files are up

35 to date.

37 include::diff-format.txt[]

@@ -48,7 +48,7 @@ Cached Mode

48 If '--cached' is specified, it allows you to ask:

50 show me the differences between HEAD and the current index

51 - contents (the ones I'd write using 'git-write-tree')

51 + contents (the ones I'd write using 'git write-tree')

53 For example, let's say that you have worked on your working directory, updated

54 some files in the index and are ready to commit. You want to see exactly

@@ -60,7 +60,7 @@ object and compare it that way, and to do that, you just do

60 Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had

61 done an `update-index` to make that effective in the index file.

62 `git diff-files` wouldn't show anything at all, since the index file

63 -matches my working directory. But doing a 'git-diff-index' does:

63 +matches my working directory. But doing a 'git diff-index' does:

65 torvalds@ppc970:~/git> git diff-index --cached HEAD

66 -100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c

@@ -69,10 +69,10 @@ matches my working directory. But doing a 'git-diff-index' does:

69 You can see easily that the above is a rename.

71 In fact, `git diff-index --cached` *should* always be entirely equivalent to

72 -actually doing a 'git-write-tree' and comparing that. Except this one is much

72 +actually doing a 'git write-tree' and comparing that. Except this one is much

73 nicer for the case where you just want to check where you are.

75 -So doing a 'git-diff-index --cached' is basically very useful when you are

75 +So doing a `git diff-index --cached` is basically very useful when you are

76 asking yourself "what have I already marked for being committed, and

77 what's the difference to a previous tree".

@@ -80,20 +80,20 @@ Non-cached Mode

80 ---------------

81 The "non-cached" mode takes a different approach, and is potentially

82 the more useful of the two in that what it does can't be emulated with

83 -a 'git-write-tree' + 'git-diff-tree'. Thus that's the default mode.

83 +a 'git write-tree' + 'git diff-tree'. Thus that's the default mode.

84 The non-cached version asks the question:

86 show me the differences between HEAD and the currently checked out

87 tree - index contents _and_ files that aren't up-to-date

89 which is obviously a very useful question too, since that tells you what

90 -you *could* commit. Again, the output matches the 'git-diff-tree -r'

90 +you *could* commit. Again, the output matches the 'git diff-tree -r'

91 output to a tee, but with a twist.

93 The twist is that if some file doesn't match the index, we don't have

94 a backing store thing for it, and we use the magic "all-zero" sha1 to

95 show that. So let's say that you have edited `kernel/sched.c`, but

96 -have not actually done a 'git-update-index' on it yet - there is no

96 +have not actually done a 'git update-index' on it yet - there is no

97 "object" associated with the new state, and you get:

99 torvalds@ppc970:~/v2.6/linux> git diff-index HEAD

@@ -104,11 +104,11 @@ not up-to-date and may contain new stuff. The all-zero sha1 means that to

104 get the real diff, you need to look at the object in the working directory

105 directly rather than do an object-to-object diff.

106

107 -NOTE: As with other commands of this type, 'git-diff-index' does not

107 +NOTE: As with other commands of this type, 'git diff-index' does not

108 actually look at the contents of the file at all. So maybe

109 `kernel/sched.c` hasn't actually changed, and it's just that you

110 touched it. In either case, it's a note that you need to

111 -'git-update-index' it to make the index be in sync.

111 +'git update-index' it to make the index be in sync.

112

113 NOTE: You can have a mixture of files show up as "has been updated"

114 and "is still dirty in the working directory" together. You can always

Documentation/git-diff-tree.txt

+5 -5

@@ -20,7 +20,7 @@ Compares the content and mode of the blobs found via two tree objects.

20 If there is only one <tree-ish> given, the commit is compared with its parents

21 (see --stdin below).

23 -Note that 'git-diff-tree' can use the tree encapsulated in a commit object.

23 +Note that 'git diff-tree' can use the tree encapsulated in a commit object.

25 OPTIONS

26 -------

@@ -67,25 +67,25 @@ The following flags further affect the behavior when comparing

67 commits (but not trees).

69 -m::

70 - By default, 'git-diff-tree --stdin' does not show

70 + By default, 'git diff-tree --stdin' does not show

71 differences for merge commits. With this flag, it shows

72 differences to that commit from all of its parents. See

73 also '-c'.

75 -s::

76 - By default, 'git-diff-tree --stdin' shows differences,

76 + By default, 'git diff-tree --stdin' shows differences,

77 either in machine-readable form (without '-p') or in patch

78 form (with '-p'). This output can be suppressed. It is

79 only useful with '-v' flag.

81 -v::

82 - This flag causes 'git-diff-tree --stdin' to also show

82 + This flag causes 'git diff-tree --stdin' to also show

83 the commit message before the differences.

85 include::pretty-options.txt[]

87 --no-commit-id::

88 - 'git-diff-tree' outputs a line with the commit ID when

88 + 'git diff-tree' outputs a line with the commit ID when

89 applicable. This flag suppressed the commit ID output.

91 -c::

Documentation/git-difftool.txt

+8 -8

@@ -11,9 +11,9 @@ SYNOPSIS

12 DESCRIPTION

13 -----------

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

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

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

16 -to 'git-diff' and accepts the same options and arguments.

16 +to 'git diff' and accepts the same options and arguments.

18 OPTIONS

19 -------

@@ -33,23 +33,23 @@ OPTIONS

33 kdiff3, kompare, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff,

34 ecmerge, diffuse, opendiff, p4merge and araxis.

35 +

36 -If a diff tool is not specified, 'git-difftool'

36 +If a diff tool is not specified, 'git difftool'

37 will use the configuration variable `diff.tool`. If the

38 -configuration variable `diff.tool` is not set, 'git-difftool'

38 +configuration variable `diff.tool` is not set, 'git difftool'

39 will pick a suitable default.

40 +

41 You can explicitly provide a full path to the tool by setting the

42 configuration variable `difftool.<tool>.path`. For example, you

43 can configure the absolute path to kdiff3 by setting

44 -`difftool.kdiff3.path`. Otherwise, 'git-difftool' assumes the

44 +`difftool.kdiff3.path`. Otherwise, 'git difftool' assumes the

45 tool is available in PATH.

46 +

47 Instead of running one of the known diff tools,

48 -'git-difftool' can be customized to run an alternative program

48 +'git difftool' can be customized to run an alternative program

49 by specifying the command line to invoke in a configuration

50 variable `difftool.<tool>.cmd`.

51 +

52 -When 'git-difftool' is invoked with this tool (either through the

52 +When 'git difftool' is invoked with this tool (either through the

53 `-t` or `--tool` option or the `diff.tool` configuration variable)

54 the configured command line will be invoked with the following

55 variables available: `$LOCAL` is set to the name of the temporary

@@ -62,7 +62,7 @@ See linkgit:git-diff[1] for the full list of supported options.

63 CONFIG VARIABLES

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

65 -'git-difftool' falls back to 'git-mergetool' config variables when the

65 +'git difftool' falls back to 'git mergetool' config variables when the

66 difftool equivalents have not been defined.

68 diff.tool::

Documentation/git-fast-export.txt

+6 -6

@@ -13,18 +13,18 @@ SYNOPSIS

13 DESCRIPTION

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

15 This program dumps the given revisions in a form suitable to be piped

16 -into 'git-fast-import'.

16 +into 'git fast-import'.

18 You can use it as a human-readable bundle replacement (see

19 linkgit:git-bundle[1]), or as a kind of an interactive

20 -'git-filter-branch'.

20 +'git filter-branch'.

23 OPTIONS

24 -------

25 --progress=<n>::

26 Insert 'progress' statements every <n> objects, to be shown by

27 - 'git-fast-import' during import.

27 + 'git fast-import' during import.

29 --signed-tags=(verbatim|warn|strip|abort)::

30 Specify how to handle signed tags. Since any transformation

@@ -91,8 +91,8 @@ marks the same across runs.

91 already contains the necessary objects.

93 [git-rev-list-args...]::

94 - A list of arguments, acceptable to 'git-rev-parse' and

95 - 'git-rev-list', that specifies the specific objects and references

94 + A list of arguments, acceptable to 'git rev-parse' and

95 + 'git rev-list', that specifies the specific objects and references

96 to export. For example, `master\~10..master` causes the

97 current master reference to be exported along with all objects

98 added since its 10th ancestor commit.

@@ -125,7 +125,7 @@ referenced by that revision range contains the string

125 Limitations

126 -----------

127

128 -Since 'git-fast-import' cannot tag trees, you will not be

128 +Since 'git fast-import' cannot tag trees, you will not be

129 able to export the linux-2.6.git repository completely, as it contains

130 a tag referencing a tree instead of a commit.

131

Documentation/git-fast-import.txt

+10 -10

@@ -15,7 +15,7 @@ DESCRIPTION

15 This program is usually not what the end user wants to run directly.

16 Most end users want to use one of the existing frontend programs,

17 which parses a specific type of foreign source and feeds the contents

18 -stored there to 'git-fast-import'.

18 +stored there to 'git fast-import'.

20 fast-import reads a mixed command/data stream from standard input and

21 writes one or more packfiles directly into the current repository.

@@ -24,7 +24,7 @@ updated branch and tag refs, fully updating the current repository

24 with the newly imported data.

26 The fast-import backend itself can import into an empty repository (one that

27 -has already been initialized by 'git-init') or incrementally

27 +has already been initialized by 'git init') or incrementally

28 update an existing populated repository. Whether or not incremental

29 imports are supported from a particular foreign source depends on

30 the frontend program in use.

@@ -82,7 +82,7 @@ OPTIONS

82 This information may be useful after importing projects

83 whose total object set exceeds the 4 GiB packfile limit,

84 as these commits can be used as edge points during calls

85 - to 'git-pack-objects'.

85 + to 'git pack-objects'.

87 --quiet::

88 Disable all non-fatal output, making fast-import silent when it

@@ -124,9 +124,9 @@ an ideal situation, given that most conversion tools are throw-away

124

125 Parallel Operation

126 ------------------

127 -Like 'git-push' or 'git-fetch', imports handled by fast-import are safe to

127 +Like 'git push' or 'git fetch', imports handled by fast-import are safe to

128 run alongside parallel `git repack -a -d` or `git gc` invocations,

129 -or any other Git operation (including 'git-prune', as loose objects

129 +or any other Git operation (including 'git prune', as loose objects

130 are never used by fast-import).

131

132 fast-import does not lock the branch or tag refs it is actively importing.

@@ -220,7 +220,7 @@ variation in formatting will cause fast-import to reject the value.

220 +

221 An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git

222 parser is accurate, but a little on the lenient side. It is the

223 -same parser used by 'git-am' when applying patches

223 +same parser used by 'git am' when applying patches

224 received from email.

225 +

226 Some malformed strings may be accepted as valid dates. In some of

@@ -256,7 +256,7 @@ timezone.

256 This particular format is supplied as its short to implement and

257 may be useful to a process that wants to create a new commit

258 right now, without needing to use a working directory or

259 -'git-update-index'.

259 +'git update-index'.

260 +

261 If separate `author` and `committer` commands are used in a `commit`

262 the timestamps may not match, as the system clock will be polled

@@ -690,7 +690,7 @@ recommended, as the frontend does not (easily) have access to the

690 complete set of bytes which normally goes into such a signature.

691 If signing is required, create lightweight tags from within fast-import with

692 `reset`, then create the annotated versions of those tags offline

693 -with the standard 'git-tag' process.

693 +with the standard 'git tag' process.

694

695 `reset`

696 ~~~~~~~

@@ -991,7 +991,7 @@ is not `refs/heads/TAG_FIXUP`).

991

992 When committing fixups, consider using `merge` to connect the

993 commit(s) which are supplying file revisions to the fixup branch.

994 -Doing so will allow tools such as 'git-blame' to track

994 +Doing so will allow tools such as 'git blame' to track

995 through the real commit history and properly annotate the source

996 files.

997

@@ -1020,7 +1020,7 @@ Repacking Historical Data

1020 ~~~~~~~~~~~~~~~~~~~~~~~~~

1021 If you are repacking very old imported data (e.g. older than the

1022 last year), consider expending some extra CPU time and supplying

1023 -\--window=50 (or higher) when you run 'git-repack'.

1023 +\--window=50 (or higher) when you run 'git repack'.

1024 This will take longer, but will also produce a smaller packfile.

1025 You only need to expend the effort once, and everyone using your

1026 project will benefit from the smaller repository.

Documentation/git-fetch-pack.txt

+3 -3

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

13 DESCRIPTION

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

15 -Usually you would want to use 'git-fetch', which is a

15 +Usually you would want to use 'git fetch', which is a

16 higher level wrapper of this command, instead.

18 Invokes 'git-upload-pack' on a possibly remote repository

@@ -33,12 +33,12 @@ OPTIONS

34 -q::

35 --quiet::

36 - Pass '-q' flag to 'git-unpack-objects'; this makes the

36 + Pass '-q' flag to 'git unpack-objects'; this makes the

37 cloning process less verbose.

39 -k::

40 --keep::

41 - Do not invoke 'git-unpack-objects' on received data, but

41 + Do not invoke 'git unpack-objects' on received data, but

42 create a single packfile out of it instead, and store it

43 in the object database. If provided twice then the pack is

44 locked against repacking.

Documentation/git-fetch.txt

+1 -1

@@ -24,7 +24,7 @@ along with the objects necessary to complete them.

25 The ref names and their object names of fetched refs are stored

26 in `.git/FETCH_HEAD`. This information is left for a later merge

27 -operation done by 'git-merge'.

27 +operation done by 'git merge'.

29 When <refspec> stores the fetched result in tracking branches,

30 the tags that point at these branches are automatically

Documentation/git-filter-branch.txt

+9 -9

@@ -116,7 +116,7 @@ OPTIONS

116 --commit-filter <command>::

117 This is the filter for performing the commit.

118 If this filter is specified, it will be called instead of the

119 - 'git-commit-tree' command, with arguments of the form

119 + 'git commit-tree' command, with arguments of the form

120 "<TREE_ID> [-p <PARENT_COMMIT_ID>]..." and the log message on

121 stdin. The commit id is expected on stdout.

122 +

@@ -127,7 +127,7 @@ have all of them as parents.

127 You can use the 'map' convenience function in this filter, and other

128 convenience functions, too. For example, calling 'skip_commit "$@"'

129 will leave out the current commit (but not its changes! If you want

130 -that, use 'git-rebase' instead).

130 +that, use 'git rebase' instead).

131 +

132 You can also use the `git_commit_non_empty_tree "$@"` instead of

133 `git commit-tree "$@"` if you don't wish to keep commits with a single parent

@@ -196,15 +196,15 @@ the nearest ancestor that was not excluded.

196

197 -f::

198 --force::

199 - 'git-filter-branch' refuses to start with an existing temporary

199 + 'git filter-branch' refuses to start with an existing temporary

200 directory or when there are already refs starting with

201 'refs/original/', unless forced.

202

203 <rev-list options>...::

204 - Arguments for 'git-rev-list'. All positive refs included by

204 + Arguments for 'git rev-list'. All positive refs included by

205 these options are rewritten. You may also specify options

206 such as '--all', but you must use '--' to separate them from

207 - the 'git-filter-branch' options.

207 + the 'git filter-branch' options.

208

209

210 Examples

@@ -221,7 +221,7 @@ However, if the file is absent from the tree of some commit,

221 a simple `rm filename` will fail for that tree and commit.

222 Thus you may instead want to use `rm -f filename` as the script.

223

224 -Using `\--index-filter` with 'git-rm' yields a significantly faster

224 +Using `\--index-filter` with 'git rm' yields a significantly faster

225 version. Like with using `rm filename`, `git rm --cached filename`

226 will fail if the file is absent from the tree of a commit. If you

227 want to "completely forget" a file, it does not matter when it entered

@@ -303,7 +303,7 @@ and all children of the merge will become merge commits with P1,P2

303 as their parents instead of the merge commit.

304

305 You can rewrite the commit log messages using `--msg-filter`. For

306 -example, 'git-svn-id' strings in a repository created by 'git-svn' can

306 +example, 'git svn-id' strings in a repository created by 'git svn' can

307 be removed this way:

308

309 -------------------------------------------------------

@@ -314,7 +314,7 @@ git filter-branch --msg-filter '

314

315 To restrict rewriting to only part of the history, specify a revision

316 range in addition to the new branch name. The new branch name will

317 -point to the top-most revision that a 'git-rev-list' of this range

317 +point to the top-most revision that a 'git rev-list' of this range

318 will print.

319

320 If you need to add 'Acked-by' lines to, say, the last 10 commits (none

@@ -330,7 +330,7 @@ git filter-branch --msg-filter '

330 *NOTE* the changes introduced by the commits, and which are not reverted

331 by subsequent commits, will still be in the rewritten branch. If you want

332 to throw out _changes_ together with the commits, you should use the

333 -interactive mode of 'git-rebase'.

333 +interactive mode of 'git rebase'.

334

335

336 Consider this history:

Documentation/git-fmt-merge-msg.txt

+1 -1

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

16 -----------

17 Takes the list of merged objects on stdin and produces a suitable

18 commit message to be used for the merge commit, usually to be

19 -passed as the '<merge-message>' argument of 'git-merge'.

19 +passed as the '<merge-message>' argument of 'git merge'.

21 This command is intended mostly for internal use by scripts

22 automatically invoking 'git merge'.

Documentation/git-for-each-ref.txt

+1 -1

@@ -82,7 +82,7 @@ objecttype::

82 The type of the object (`blob`, `tree`, `commit`, `tag`).

84 objectsize::

85 - The size of the object (the same as 'git-cat-file -s' reports).

85 + The size of the object (the same as 'git cat-file -s' reports).

87 objectname::

88 The object name (aka SHA-1).

Documentation/git-format-patch.txt

+2 -2

@@ -29,7 +29,7 @@ DESCRIPTION

29 Prepare each commit with its patch in

30 one file per commit, formatted to resemble UNIX mailbox format.

31 The output of this command is convenient for e-mail submission or

32 -for use with 'git-am'.

32 +for use with 'git am'.

34 There are two ways to specify which commits to operate on.

@@ -221,7 +221,7 @@ EXAMPLES

221 --------

222

223 * Extract commits between revisions R1 and R2, and apply them on top of

224 -the current branch using 'git-am' to cherry-pick them:

224 +the current branch using 'git am' to cherry-pick them:

225 +

226 ------------

227 $ git format-patch -k --stdout R1..R2 | git am -3 -k

Documentation/git-fsck.txt

+2 -2

@@ -21,7 +21,7 @@ OPTIONS

21 <object>::

22 An object to treat as the head of an unreachability trace.

23 +

24 -If no objects are given, 'git-fsck' defaults to using the

24 +If no objects are given, 'git fsck' defaults to using the

25 index file, all SHA1 references in .git/refs/*, and all reflogs (unless

26 --no-reflogs is given) as heads.

@@ -85,7 +85,7 @@ So for example

86 will do quite a _lot_ of verification on the tree. There are a few

87 extra validity tests to be added (make sure that tree objects are

88 -sorted properly etc), but on the whole if 'git-fsck' is happy, you

88 +sorted properly etc), but on the whole if 'git fsck' is happy, you

89 do have a valid tree.

91 Any corrupt objects you will have to find in backups or other archives

Documentation/git-gc.txt

+10 -10

@@ -15,13 +15,13 @@ DESCRIPTION

15 Runs a number of housekeeping tasks within the current repository,

16 such as compressing file revisions (to reduce disk space and increase

17 performance) and removing unreachable objects which may have been

18 -created from prior invocations of 'git-add'.

18 +created from prior invocations of 'git add'.

20 Users are encouraged to run this task on a regular basis within

21 each repository to maintain good disk space utilization and good

22 operating performance.

24 -Some git commands may automatically run 'git-gc'; see the `--auto` flag

24 +Some git commands may automatically run 'git gc'; see the `--auto` flag

25 below for details. If you know what you're doing and all you want is to

26 disable this behavior permanently without further considerations, just do:

@@ -33,15 +33,15 @@ OPTIONS

33 -------

35 --aggressive::

36 - Usually 'git-gc' runs very quickly while providing good disk

36 + Usually 'git gc' runs very quickly while providing good disk

37 space utilization and performance. This option will cause

38 - 'git-gc' to more aggressively optimize the repository at the expense

38 + 'git gc' to more aggressively optimize the repository at the expense

39 of taking much more time. The effects of this optimization are

40 persistent, so this option only needs to be used occasionally; every

41 few hundred changesets or so.

43 --auto::

44 - With this option, 'git-gc' checks whether any housekeeping is

44 + With this option, 'git gc' checks whether any housekeeping is

45 required; if not, it exits without performing any work.

46 Some git commands run `git gc --auto` after performing

47 operations that could create many loose objects.

@@ -50,13 +50,13 @@ Housekeeping is required if there are too many loose objects or

50 too many packs in the repository. If the number of loose objects

51 exceeds the value of the `gc.auto` configuration variable, then

52 all loose objects are combined into a single pack using

53 -`git-repack -d -l`. Setting the value of `gc.auto` to 0

53 +`git repack -d -l`. Setting the value of `gc.auto` to 0

54 disables automatic packing of loose objects.

55 +

56 If the number of packs exceeds the value of `gc.autopacklimit`,

57 then existing packs (except those marked with a `.keep` file)

58 are consolidated into a single pack by using the `-A` option of

59 -'git-repack'. Setting `gc.autopacklimit` to 0 disables

59 +'git repack'. Setting `gc.autopacklimit` to 0 disables

60 automatic consolidation of packs.

62 --prune=<date>::

@@ -97,7 +97,7 @@ how long records of conflicted merge you have not resolved are

97 kept. This defaults to 15 days.

99 The optional configuration variable 'gc.packrefs' determines if

100 -'git-gc' runs 'git-pack-refs'. This can be set to "nobare" to enable

100 +'git gc' runs 'git pack-refs'. This can be set to "nobare" to enable

101 it within all non-bare repos or it can be set to a boolean value.

102 This defaults to true.

103

@@ -116,10 +116,10 @@ default is "2 weeks ago".

116 Notes

117 -----

118

119 -'git-gc' tries very hard to be safe about the garbage it collects. In

119 +'git gc' tries very hard to be safe about the garbage it collects. In

120 particular, it will keep not only objects referenced by your current set

121 of branches and tags, but also objects referenced by the index, remote

122 -tracking branches, refs saved by 'git-filter-branch' in

122 +tracking branches, refs saved by 'git filter-branch' in

123 refs/original/, or reflogs (which may reference commits in branches

124 that were later amended or rewound).

125

Documentation/git-get-tar-commit-id.txt

+3 -3

@@ -14,12 +14,12 @@ SYNOPSIS

14 DESCRIPTION

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

16 Acts as a filter, extracting the commit ID stored in archives created by

17 -'git-archive'. It reads only the first 1024 bytes of input, thus its

17 +'git archive'. It reads only the first 1024 bytes of input, thus its

18 runtime is not influenced by the size of <tarfile> very much.

20 -If no commit ID is found, 'git-get-tar-commit-id' quietly exists with a

20 +If no commit ID is found, 'git get-tar-commit-id' quietly exists with a

21 return code of 1. This can happen if <tarfile> had not been created

22 -using 'git-archive' or if the first parameter of 'git-archive' had been

22 +using 'git archive' or if the first parameter of 'git archive' had been

23 a tree ID instead of a commit ID or tag.

Documentation/git-grep.txt

+1 -1

@@ -98,7 +98,7 @@ OPTIONS

98 --files-without-match::

99 Instead of showing every matched line, show only the

100 names of files that contain (or do not contain) matches.

101 - For better compatibility with 'git-diff', --name-only is a

101 + For better compatibility with 'git diff', --name-only is a

102 synonym for --files-with-matches.

103

104 -z::

Documentation/git-gui.txt

+10 -10

@@ -11,19 +11,19 @@ SYNOPSIS

12 DESCRIPTION

13 -----------

14 -A Tcl/Tk based graphical user interface to Git. 'git-gui' focuses

14 +A Tcl/Tk based graphical user interface to Git. 'git gui' focuses

15 on allowing users to make changes to their repository by making

16 new commits, amending existing ones, creating branches, performing

17 local merges, and fetching/pushing to remote repositories.

19 -Unlike 'gitk', 'git-gui' focuses on commit generation

19 +Unlike 'gitk', 'git gui' focuses on commit generation

20 and single file annotation and does not show project history.

21 It does however supply menu actions to start a 'gitk' session from

22 -within 'git-gui'.

22 +within 'git gui'.

24 -'git-gui' is known to work on all popular UNIX systems, Mac OS X,

24 +'git gui' is known to work on all popular UNIX systems, Mac OS X,

25 and Windows (under both Cygwin and MSYS). To the extent possible

26 -OS specific user interface guidelines are followed, making 'git-gui'

26 +OS specific user interface guidelines are followed, making 'git gui'

27 a fairly native interface for users.

29 COMMANDS

@@ -38,13 +38,13 @@ browser::

38 browser are opened in the blame viewer.

40 citool::

41 - Start 'git-gui' and arrange to make exactly one commit before

41 + Start 'git gui' and arrange to make exactly one commit before

42 exiting and returning to the shell. The interface is limited

43 to only commit actions, slightly reducing the application's

44 startup time and simplifying the menubar.

46 version::

47 - Display the currently running version of 'git-gui'.

47 + Display the currently running version of 'git gui'.

50 Examples

@@ -103,15 +103,15 @@ SEE ALSO

103 linkgit:gitk[1]::

104 The git repository browser. Shows branches, commit history

105 and file differences. gitk is the utility started by

106 - 'git-gui''s Repository Visualize actions.

106 + 'git gui''s Repository Visualize actions.

107

108 Other

109 -----

110 -'git-gui' is actually maintained as an independent project, but stable

110 +'git gui' is actually maintained as an independent project, but stable

111 versions are distributed as part of the Git suite for the convenience

112 of end users.

113

114 -A 'git-gui' development repository can be obtained from:

114 +A 'git gui' development repository can be obtained from:

115

116 git clone git://repo.or.cz/git-gui.git

117

Documentation/git-hash-object.txt

+1 -1

@@ -18,7 +18,7 @@ Computes the object ID value for an object with specified type

18 with the contents of the named file (which can be outside of the

19 work tree), and optionally writes the resulting object into the

20 object database. Reports its object ID to its standard output.

21 -This is used by 'git-cvsimport' to update the index

21 +This is used by 'git cvsimport' to update the index

22 without modifying files in the work tree. When <type> is not

23 specified, it defaults to "blob".

Documentation/git-help.txt

+4 -4

@@ -55,8 +55,8 @@ other display programs (see below).

55 +

56 The web browser can be specified using the configuration variable

57 'help.browser', or 'web.browser' if the former is not set. If none of

58 -these config variables is set, the 'git-web--browse' helper script

59 -(called by 'git-help') will pick a suitable default. See

58 +these config variables is set, the 'git web--browse' helper script

59 +(called by 'git help') will pick a suitable default. See

60 linkgit:git-web--browse[1] for more information about this.

62 CONFIGURATION VARIABLES

@@ -67,7 +67,7 @@ help.format

68 If no command line option is passed, the 'help.format' configuration

69 variable will be checked. The following values are supported for this

70 -variable; they make 'git-help' behave as their corresponding command

70 +variable; they make 'git help' behave as their corresponding command

71 line option:

73 * "man" corresponds to '-m|--man',

@@ -122,7 +122,7 @@ man.<tool>.path

122 You can explicitly provide a full path to your preferred man viewer by

123 setting the configuration variable 'man.<tool>.path'. For example, you

124 can configure the absolute path to konqueror by setting

125 -'man.konqueror.path'. Otherwise, 'git-help' assumes the tool is

125 +'man.konqueror.path'. Otherwise, 'git help' assumes the tool is

126 available in PATH.

127

128 man.<tool>.cmd

Documentation/git-http-backend.txt

+11 -11

@@ -8,7 +8,7 @@ git-http-backend - Server side implementation of Git over HTTP

8 SYNOPSIS

9 --------

10 [verse]

11 -'git-http-backend'

11 +'git http-backend'

13 DESCRIPTION

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

@@ -19,10 +19,10 @@ and the backwards-compatible dumb HTTP protocol, as well as clients

19 pushing using the smart HTTP protocol.

21 By default, only the `upload-pack` service is enabled, which serves

22 -'git-fetch-pack' and 'git-ls-remote' clients, which are invoked from

23 -'git-fetch', 'git-pull', and 'git-clone'. If the client is authenticated,

24 -the `receive-pack` service is enabled, which serves 'git-send-pack'

25 -clients, which is invoked from 'git-push'.

22 +'git fetch-pack' and 'git ls-remote' clients, which are invoked from

23 +'git fetch', 'git pull', and 'git clone'. If the client is authenticated,

24 +the `receive-pack` service is enabled, which serves 'git send-pack'

25 +clients, which is invoked from 'git push'.

27 SERVICES

28 --------

@@ -38,12 +38,12 @@ http.getanyfile::

38 by setting this configuration item to `false`.

40 http.uploadpack::

41 - This serves 'git-fetch-pack' and 'git-ls-remote' clients.

41 + This serves 'git fetch-pack' and 'git ls-remote' clients.

42 It is enabled by default, but a repository can disable it

43 by setting this configuration item to `false`.

45 http.receivepack::

46 - This serves 'git-send-pack' clients, allowing push. It is

46 + This serves 'git send-pack' clients, allowing push. It is

47 disabled by default for anonymous users, and enabled by

48 default for users authenticated by the web server. It can be

49 disabled by setting this item to `false`, or enabled for all

@@ -51,11 +51,11 @@ http.receivepack::

52 URL TRANSLATION

53 ---------------

54 -To determine the location of the repository on disk, 'git-http-backend'

54 +To determine the location of the repository on disk, 'git http-backend'

55 concatenates the environment variables PATH_INFO, which is set

56 automatically by the web server, and GIT_PROJECT_ROOT, which must be set

57 manually in the web server configuration. If GIT_PROJECT_ROOT is not

58 -set, 'git-http-backend' reads PATH_TRANSLATED, which is also set

58 +set, 'git http-backend' reads PATH_TRANSLATED, which is also set

59 automatically by the web server.

61 EXAMPLES

@@ -98,7 +98,7 @@ directive around the repository, or one of its parent directories:

98 ----------------------------------------------------------------

99 +

100 To serve gitweb at the same url, use a ScriptAliasMatch to only

101 -those URLs that 'git-http-backend' can handle, and forward the

101 +those URLs that 'git http-backend' can handle, and forward the

102 rest to gitweb:

103 +

104 ----------------------------------------------------------------

@@ -147,7 +147,7 @@ ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/

147

148 ENVIRONMENT

149 -----------

150 -'git-http-backend' relies upon the CGI environment variables set

150 +'git http-backend' relies upon the CGI environment variables set

151 by the invoking web server, including:

152

153 * PATH_INFO (if GIT_PROJECT_ROOT is set, otherwise PATH_TRANSLATED)

Documentation/git-http-fetch.txt

+1 -1

@@ -35,7 +35,7 @@ commit-id::

36 --stdin::

37 Instead of a commit id on the command line (which is not expected in this

38 - case), 'git-http-fetch' expects lines on stdin in the format

38 + case), 'git http-fetch' expects lines on stdin in the format

40 <commit-id>['\t'<filename-as-in--w>]

Documentation/git-imap-send.txt

+1 -1

@@ -13,7 +13,7 @@ SYNOPSIS

14 DESCRIPTION

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

16 -This command uploads a mailbox generated with 'git-format-patch'

16 +This command uploads a mailbox generated with 'git format-patch'

17 into an IMAP drafts folder. This allows patches to be sent as

18 other email is when using mail clients that cannot read mailbox

19 files directly.

Documentation/git-index-pack.txt

+4 -4

@@ -43,10 +43,10 @@ OPTIONS

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

46 - 'git-repack'.

46 + 'git repack'.

48 --fix-thin::

49 - It is possible for 'git-pack-objects' to build

49 + It is possible for 'git pack-objects' to build

50 "thin" pack, which records objects in deltified form based on

51 objects not included in the pack to reduce network traffic.

52 Those objects are expected to be present on the receiving end

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

59 Before moving the index into its final destination

60 create an empty .keep file for the associated pack file.

61 This option is usually necessary with --stdin to prevent a

62 - simultaneous 'git-repack' process from deleting

62 + simultaneous 'git repack' process from deleting

63 the newly constructed pack and index before refs can be

64 updated to use objects contained in the pack.

@@ -86,7 +86,7 @@ Once the index has been created, the list of object names is sorted

86 and the SHA1 hash of that list is printed to stdout. If --stdin was

87 also used then this is prefixed by either "pack\t", or "keep\t" if a

88 new .keep file was successfully created. This is useful to remove a

89 -.keep file used as a lock to prevent the race with 'git-repack'

89 +.keep file used as a lock to prevent the race with 'git repack'

90 mentioned above.

Documentation/git-init.txt

+3 -3

@@ -95,11 +95,11 @@ If the object storage directory is specified via the `$GIT_OBJECT_DIRECTORY`

95 environment variable then the sha1 directories are created underneath -

96 otherwise the default `$GIT_DIR/objects` directory is used.

98 -Running 'git-init' in an existing repository is safe. It will not overwrite

99 -things that are already there. The primary reason for rerunning 'git-init'

98 +Running 'git init' in an existing repository is safe. It will not overwrite

99 +things that are already there. The primary reason for rerunning 'git init'

100 is to pick up newly added templates.

101

102 -Note that 'git-init' is the same as 'git-init-db'. The command

102 +Note that 'git init' is the same as 'git init-db'. The command

103 was primarily meant to initialize the object database, but over

104 time it has become responsible for setting up the other aspects

105 of the repository, such as installing the default hooks and

Documentation/git-instaweb.txt

+1 -1

@@ -44,7 +44,7 @@ OPTIONS

44 -b::

45 --browser::

46 The web browser that should be used to view the gitweb

47 - page. This will be passed to the 'git-web--browse' helper

47 + page. This will be passed to the 'git web--browse' helper

48 script along with the URL of the gitweb instance. See

49 linkgit:git-web--browse[1] for more information about this. If

50 the script fails, the URL will be printed to stdout.

Documentation/git-log.txt

+2 -2

@@ -14,9 +14,9 @@ DESCRIPTION

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

15 Shows the commit logs.

17 -The command takes options applicable to the 'git-rev-list'

17 +The command takes options applicable to the 'git rev-list'

18 command to control what is shown and how, and options applicable to

19 -the 'git-diff-*' commands to control how the changes

19 +the 'git diff-*' commands to control how the changes

20 each commit introduces are shown.

Documentation/git-ls-files.txt

+3 -3

@@ -145,7 +145,7 @@ which case it outputs:

145

146 [<tag> ]<mode> <object> <stage> <file>

147

148 -'git-ls-files --unmerged' and 'git-ls-files --stage' can be used to examine

148 +'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine

149 detailed information on unmerged paths.

150

151 For an unmerged path, instead of recording a single mode/SHA1 pair,

@@ -162,7 +162,7 @@ respectively.

162 Exclude Patterns

163 ----------------

164

165 -'git-ls-files' can use a list of "exclude patterns" when

165 +'git ls-files' can use a list of "exclude patterns" when

166 traversing the directory tree and finding files to show when the

167 flags --others or --ignored are specified. linkgit:gitignore[5]

168 specifies the format of exclude patterns.

@@ -178,7 +178,7 @@ These exclude patterns come from these places, in order:

178 in the same order they appear in the file.

179

180 3. command line flag --exclude-per-directory=<name> specifies

181 - a name of the file in each directory 'git-ls-files'

181 + a name of the file in each directory 'git ls-files'

182 examines, normally `.gitignore`. Files in deeper

183 directories take precedence. Patterns are ordered in the

184 same order they appear in the files.

Documentation/git-mailinfo.txt

+2 -2

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

16 Reads a single e-mail message from the standard input, and

17 writes the commit log message in <msg> file, and the patches in

18 <patch> file. The author name, e-mail and e-mail subject are

19 -written out to the standard output to be used by 'git-am'

19 +written out to the standard output to be used by 'git am'

20 to create a commit. It is usually not necessary to use this

21 command directly. See linkgit:git-am[1] instead.

@@ -30,7 +30,7 @@ OPTIONS

30 whitespaces, (3) '[' up to ']', typically '[PATCH]', and

31 then prepends "[PATCH] ". This flag forbids this

32 munging, and is most useful when used to read back

33 - 'git-format-patch -k' output.

33 + 'git format-patch -k' output.

35 -b::

36 When -k is not in effect, all leading strings bracketed with '['

Documentation/git-merge-file.txt

+5 -5

@@ -15,15 +15,15 @@ SYNOPSIS

16 DESCRIPTION

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

18 -'git-merge-file' incorporates all changes that lead from the `<base-file>`

18 +'git merge-file' incorporates all changes that lead from the `<base-file>`

19 to `<other-file>` into `<current-file>`. The result ordinarily goes into

20 -`<current-file>`. 'git-merge-file' is useful for combining separate changes

20 +`<current-file>`. 'git merge-file' is useful for combining separate changes

21 to an original. Suppose `<base-file>` is the original, and both

22 `<current-file>` and `<other-file>` are modifications of `<base-file>`,

23 -then 'git-merge-file' combines both changes.

23 +then 'git merge-file' combines both changes.

25 A conflict occurs if both `<current-file>` and `<other-file>` have changes

26 -in a common segment of lines. If a conflict is found, 'git-merge-file'

26 +in a common segment of lines. If a conflict is found, 'git merge-file'

27 normally outputs a warning and brackets the conflict with lines containing

28 <<<<<<< and >>>>>>> markers. A typical conflict will look like this:

@@ -39,7 +39,7 @@ the alternatives.

39 The exit value of this program is negative on error, and the number of

40 conflicts otherwise. If the merge was clean, the exit value is 0.

42 -'git-merge-file' is designed to be a minimal clone of RCS 'merge'; that is, it

42 +'git merge-file' is designed to be a minimal clone of RCS 'merge'; that is, it

43 implements all of RCS 'merge''s functionality which is needed by

44 linkgit:git[1].

Documentation/git-merge-index.txt

+4 -4

@@ -36,14 +36,14 @@ OPTIONS

36 failure usually indicates conflicts during the merge). This is for

37 porcelains which might want to emit custom messages.

39 -If 'git-merge-index' is called with multiple <file>s (or -a) then it

39 +If 'git merge-index' is called with multiple <file>s (or -a) then it

40 processes them in turn only stopping if merge returns a non-zero exit

41 code.

43 Typically this is run with a script calling git's imitation of

44 the 'merge' command from the RCS package.

46 -A sample script called 'git-merge-one-file' is included in the

46 +A sample script called 'git merge-one-file' is included in the

47 distribution.

49 ALERT ALERT ALERT! The git "merge object order" is different from the

@@ -68,10 +68,10 @@ or

68 This is added AA in the branch B.

69 fatal: merge program failed

71 -where the latter example shows how 'git-merge-index' will stop trying to

71 +where the latter example shows how 'git merge-index' will stop trying to

72 merge once anything has returned an error (i.e., `cat` returned an error

73 for the AA file, because it didn't exist in the original, and thus

74 -'git-merge-index' didn't even try to merge the MM thing).

74 +'git merge-index' didn't even try to merge the MM thing).

76 Author

77 ------

Documentation/git-merge-one-file.txt

+3 -3

@@ -8,12 +8,12 @@ git-merge-one-file - The standard helper program to use with git-merge-index

9 SYNOPSIS

10 --------

11 -'git-merge-one-file'

11 +'git merge-one-file'

13 DESCRIPTION

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

15 -This is the standard helper program to use with 'git-merge-index'

16 -to resolve a merge after the trivial merge done with 'git-read-tree -m'.

15 +This is the standard helper program to use with 'git merge-index'

16 +to resolve a merge after the trivial merge done with 'git read-tree -m'.

18 Author

19 ------

Documentation/git-merge.txt

+3 -3

@@ -22,7 +22,7 @@ The second syntax (<msg> `HEAD` <commit>...) is supported for

22 historical reasons. Do not use it from the command line or in

23 new scripts. It is the same as `git merge -m <msg> <commit>...`.

25 -*Warning*: Running 'git-merge' with uncommitted changes is

25 +*Warning*: Running 'git merge' with uncommitted changes is

26 discouraged: while possible, it leaves you in a state that is hard to

27 back out of in the case of a conflict.

@@ -46,7 +46,7 @@ include::merge-strategies.txt[]

48 If you tried a merge which resulted in complex conflicts and

49 -want to start over, you can recover with 'git-reset'.

49 +want to start over, you can recover with 'git reset'.

51 CONFIGURATION

52 -------------

@@ -198,7 +198,7 @@ After seeing a conflict, you can do two things:

198

199 * Resolve the conflicts. Git will mark the conflicts in

200 the working tree. Edit the files into shape and

201 - 'git-add' them to the index. Use 'git-commit' to seal the deal.

201 + 'git add' them to the index. Use 'git commit' to seal the deal.

202

203 You can work through the conflict with a number of tools:

204

Documentation/git-mergetool.txt

+8 -8

@@ -13,11 +13,11 @@ DESCRIPTION

13 -----------

15 Use `git mergetool` to run one of several merge utilities to resolve

16 -merge conflicts. It is typically run after 'git-merge'.

16 +merge conflicts. It is typically run after 'git merge'.

18 If one or more <file> parameters are given, the merge tool program will

19 be run to resolve differences on each file. If no <file> names are

20 -specified, 'git-mergetool' will run the merge tool program on every file

20 +specified, 'git mergetool' will run the merge tool program on every file

21 with merge conflicts.

23 OPTIONS

@@ -29,23 +29,23 @@ OPTIONS

29 kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge,

30 diffuse, tortoisemerge, opendiff, p4merge and araxis.

31 +

32 -If a merge resolution program is not specified, 'git-mergetool'

32 +If a merge resolution program is not specified, 'git mergetool'

33 will use the configuration variable `merge.tool`. If the

34 -configuration variable `merge.tool` is not set, 'git-mergetool'

34 +configuration variable `merge.tool` is not set, 'git mergetool'

35 will pick a suitable default.

36 +

37 You can explicitly provide a full path to the tool by setting the

38 configuration variable `mergetool.<tool>.path`. For example, you

39 can configure the absolute path to kdiff3 by setting

40 -`mergetool.kdiff3.path`. Otherwise, 'git-mergetool' assumes the

40 +`mergetool.kdiff3.path`. Otherwise, 'git mergetool' assumes the

41 tool is available in PATH.

42 +

43 Instead of running one of the known merge tool programs,

44 -'git-mergetool' can be customized to run an alternative program

44 +'git mergetool' can be customized to run an alternative program

45 by specifying the command line to invoke in a configuration

46 variable `mergetool.<tool>.cmd`.

47 +

48 -When 'git-mergetool' is invoked with this tool (either through the

48 +When 'git mergetool' is invoked with this tool (either through the

49 `-t` or `--tool` option or the `merge.tool` configuration

50 variable) the configured command line will be invoked with `$BASE`

51 set to the name of a temporary file containing the common base for

@@ -59,7 +59,7 @@ merge resolution.

59 If the custom merge tool correctly indicates the success of a

60 merge resolution with its exit code, then the configuration

61 variable `mergetool.<tool>.trustExitCode` can be set to `true`.

62 -Otherwise, 'git-mergetool' will prompt the user to indicate the

62 +Otherwise, 'git mergetool' will prompt the user to indicate the

63 success of the resolution after the custom tool has exited.

65 -y::

Documentation/git-name-rev.txt

+2 -2

@@ -15,7 +15,7 @@ SYNOPSIS

15 DESCRIPTION

16 -----------

17 Finds symbolic names suitable for human digestion for revisions given in any

18 -format parsable by 'git-rev-parse'.

18 +format parsable by 'git rev-parse'.

21 OPTIONS

@@ -55,7 +55,7 @@ wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.

55 Of course, you look into the commit, but that only tells you what happened, but

56 not the context.

58 -Enter 'git-name-rev':

58 +Enter 'git name-rev':

60 ------------

61 % git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a

Documentation/git-notes.txt

+1 -1

@@ -8,7 +8,7 @@ git-notes - Add/inspect commit notes

8 SYNOPSIS

9 --------

10 [verse]

11 -'git-notes' (edit [-F <file> | -m <msg>] | show) [commit]

11 +'git notes' (edit [-F <file> | -m <msg>] | show) [commit]

13 DESCRIPTION

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

Documentation/git-pack-objects.txt

+3 -3

@@ -32,7 +32,7 @@ Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or

32 any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)

33 enables git to read from such an archive.

35 -The 'git-unpack-objects' command can read the packed archive and

35 +The 'git unpack-objects' command can read the packed archive and

36 expand the objects contained in the pack into "one-file

37 one-object" format; this is typically done by the smart-pull

38 commands when a pack is created on-the-fly for efficient network

@@ -61,7 +61,7 @@ base-name::

61 --revs::

62 Read the revision arguments from the standard input, instead of

63 individual object names. The revision arguments are processed

64 - the same way as 'git-rev-list' with the `--objects` flag

64 + the same way as 'git rev-list' with the `--objects` flag

65 uses its `commit` arguments to build the list of objects it

66 outputs. The objects on the resulting list are packed.

@@ -182,7 +182,7 @@ base-name::

182 A packed archive can express base object of a delta as

183 either 20-byte object name or as an offset in the

184 stream, but older version of git does not understand the

185 - latter. By default, 'git-pack-objects' only uses the

185 + latter. By default, 'git pack-objects' only uses the

186 former format for better compatibility. This option

187 allows the command to use the latter format for

188 compactness. Depending on the average delta chain

Documentation/git-pack-redundant.txt

+1 -1

@@ -16,7 +16,7 @@ This program computes which packs in your repository

16 are redundant. The output is suitable for piping to

17 `xargs rm` if you are in the root of the repository.

19 -'git-pack-redundant' accepts a list of objects on standard input. Any objects

19 +'git pack-redundant' accepts a list of objects on standard input. Any objects

20 given will be ignored when checking which packs are required. This makes the

21 following command useful when wanting to remove packs which contain unreachable

22 objects.

Documentation/git-patch-id.txt

+1 -1

@@ -18,7 +18,7 @@ ID" are almost guaranteed to be the same thing.

19 IOW, you can use this thing to look for likely duplicate commits.

21 -When dealing with 'git-diff-tree' output, it takes advantage of

21 +When dealing with 'git diff-tree' output, it takes advantage of

22 the fact that the patch is prefixed with the object name of the

23 commit, and outputs two 40-byte hexadecimal strings. The first

24 string is the patch ID, and the second string is the commit ID.

Documentation/git-peek-remote.txt

+1 -1

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

13 DESCRIPTION

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

15 -This command is deprecated; use 'git-ls-remote' instead.

15 +This command is deprecated; use 'git ls-remote' instead.

17 OPTIONS

18 -------

Documentation/git-prune.txt

+8 -8

@@ -8,21 +8,21 @@ git-prune - Prune all unreachable objects from the object database

9 SYNOPSIS

10 --------

11 -'git-prune' [-n] [-v] [--expire <expire>] [--] [<head>...]

11 +'git prune' [-n] [-v] [--expire <expire>] [--] [<head>...]

13 DESCRIPTION

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

16 -NOTE: In most cases, users should run 'git-gc', which calls

17 -'git-prune'. See the section "NOTES", below.

16 +NOTE: In most cases, users should run 'git gc', which calls

17 +'git prune'. See the section "NOTES", below.

19 -This runs 'git-fsck --unreachable' using all the refs

19 +This runs 'git fsck --unreachable' using all the refs

20 available in `$GIT_DIR/refs`, optionally with additional set of

21 objects specified on the command line, and prunes all unpacked

22 objects unreachable from any of these head objects from the object database.

23 In addition, it

24 prunes the unpacked objects that are also found in packs by

25 -running 'git-prune-packed'.

25 +running 'git prune-packed'.

27 Note that unreachable, packed objects will remain. If this is

28 not desired, see linkgit:git-repack[1].

@@ -62,12 +62,12 @@ $ git prune $(cd ../another && $(git rev-parse --all))

62 Notes

63 -----

65 -In most cases, users will not need to call 'git-prune' directly, but

66 -should instead call 'git-gc', which handles pruning along with

65 +In most cases, users will not need to call 'git prune' directly, but

66 +should instead call 'git gc', which handles pruning along with

67 many other housekeeping tasks.

69 For a description of which objects are considered for pruning, see

70 -'git-fsck''s --unreachable option.

70 +'git fsck''s --unreachable option.

72 SEE ALSO

73 --------

Documentation/git-pull.txt

+6 -6

@@ -13,18 +13,18 @@ SYNOPSIS

14 DESCRIPTION

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

16 -Runs 'git-fetch' with the given parameters, and calls 'git-merge'

16 +Runs 'git fetch' with the given parameters, and calls 'git merge'

17 to merge the retrieved head(s) into the current branch.

18 -With `--rebase`, calls 'git-rebase' instead of 'git-merge'.

18 +With `--rebase`, calls 'git rebase' instead of 'git merge'.

20 Note that you can use `.` (current directory) as the

21 <repository> to pull from the local repository -- this is useful

22 when merging local branches into the current branch.

24 -Also note that options meant for 'git-pull' itself and underlying

25 -'git-merge' must be given before the options meant for 'git-fetch'.

24 +Also note that options meant for 'git pull' itself and underlying

25 +'git merge' must be given before the options meant for 'git fetch'.

27 -*Warning*: Running 'git-pull' (actually, the underlying 'git-merge')

27 +*Warning*: Running 'git pull' (actually, the underlying 'git merge')

28 with uncommitted changes is discouraged: while possible, it leaves you

29 in a state that is hard to back out of in the case of a conflict.

@@ -152,7 +152,7 @@ $ git merge origin/next

152

153

154 If you tried a pull which resulted in a complex conflicts and

155 -would want to start over, you can recover with 'git-reset'.

155 +would want to start over, you can recover with 'git reset'.

156

157

158 SEE ALSO

Documentation/git-push.txt

+3 -3

@@ -112,7 +112,7 @@ nor in any Push line of the corresponding remotes file---see below).

112

113 --repo=<repository>::

114 This option is only relevant if no <repository> argument is

115 - passed in the invocation. In this case, 'git-push' derives the

115 + passed in the invocation. In this case, 'git push' derives the

116 remote name from the current branch: If it tracks a remote

117 branch, then that remote repository is pushed to. Otherwise,

118 the name "origin" is used. For this latter case, this option

@@ -126,11 +126,11 @@ git push --repo=public #2

126 +

127 is that #1 always pushes to "public" whereas #2 pushes to "public"

128 only if the current branch does not track a remote branch. This is

129 -useful if you write an alias or script around 'git-push'.

129 +useful if you write an alias or script around 'git push'.

130

131 --thin::

132 --no-thin::

133 - These options are passed to 'git-send-pack'. Thin

133 + These options are passed to 'git send-pack'. Thin

134 transfer spends extra cycles to minimize the number of

135 objects to be sent and meant to be used on slower connection.

136

Documentation/git-read-tree.txt

+21 -21

@@ -25,8 +25,8 @@ fast-forward (i.e. 2-way) merge, or a 3-way merge, with the `-m`

25 flag. When used with `-m`, the `-u` flag causes it to also update

26 the files in the work tree with the result of the merge.

28 -Trivial merges are done by 'git-read-tree' itself. Only conflicting paths

29 -will be in unmerged state when 'git-read-tree' returns.

28 +Trivial merges are done by 'git read-tree' itself. Only conflicting paths

29 +will be in unmerged state when 'git read-tree' returns.

31 OPTIONS

32 -------

@@ -57,13 +57,13 @@ OPTIONS

57 Show the progress of checking files out.

59 --trivial::

60 - Restrict three-way merge by 'git-read-tree' to happen

60 + Restrict three-way merge by 'git read-tree' to happen

61 only if there is no file-level merging required, instead

62 of resolving merge for trivial cases and leaving

63 conflicting files unresolved in the index.

65 --aggressive::

66 - Usually a three-way merge by 'git-read-tree' resolves

66 + Usually a three-way merge by 'git read-tree' resolves

67 the merge for really trivial cases and leaves other

68 cases unresolved in the index, so that Porcelains can

69 implement different merge policies. This flag makes the

@@ -116,7 +116,7 @@ OPTIONS

116

117 Merging

118 -------

119 -If `-m` is specified, 'git-read-tree' can perform 3 kinds of

119 +If `-m` is specified, 'git read-tree' can perform 3 kinds of

120 merge, a single tree merge if only 1 tree is given, a

121 fast-forward merge with 2 trees, or a 3-way merge if 3 trees are

122 provided.

@@ -124,18 +124,18 @@ provided.

124

125 Single Tree Merge

126 ~~~~~~~~~~~~~~~~~

127 -If only 1 tree is specified, 'git-read-tree' operates as if the user did not

127 +If only 1 tree is specified, 'git read-tree' operates as if the user did not

128 specify `-m`, except that if the original index has an entry for a

129 given pathname, and the contents of the path matches with the tree

130 being read, the stat info from the index is used. (In other words, the

131 index's stat()s take precedence over the merged tree's).

132

133 That means that if you do a `git read-tree -m <newtree>` followed by a

134 -`git checkout-index -f -u -a`, the 'git-checkout-index' only checks out

134 +`git checkout-index -f -u -a`, the 'git checkout-index' only checks out

135 the stuff that really changed.

136

137 -This is used to avoid unnecessary false hits when 'git-diff-files' is

138 -run after 'git-read-tree'.

137 +This is used to avoid unnecessary false hits when 'git diff-files' is

138 +run after 'git read-tree'.

139

140

141 Two Tree Merge

@@ -146,7 +146,7 @@ is the head commit of the current repository, and $M is the head

146 of a foreign tree, which is simply ahead of $H (i.e. we are in a

147 fast-forward situation).

148

149 -When two trees are specified, the user is telling 'git-read-tree'

149 +When two trees are specified, the user is telling 'git read-tree'

150 the following:

151

152 1. The current index and work tree is derived from $H, but

@@ -199,10 +199,10 @@ Here are the "carry forward" rules:

199

200 In all "keep index" cases, the index entry stays as in the

201 original index file. If the entry were not up to date,

202 -'git-read-tree' keeps the copy in the work tree intact when

202 +'git read-tree' keeps the copy in the work tree intact when

203 operating under the -u flag.

204

205 -When this form of 'git-read-tree' returns successfully, you can

205 +When this form of 'git read-tree' returns successfully, you can

206 see what "local changes" you made are carried forward by running

207 `git diff-index --cached $M`. Note that this does not

208 necessarily match `git diff-index --cached $H` would have

@@ -225,7 +225,7 @@ of the path is kept as long as $H and $M are the same.

225 Each "index" entry has two bits worth of "stage" state. stage 0 is the

226 normal one, and is the only one you'd see in any kind of normal use.

227

228 -However, when you do 'git-read-tree' with three trees, the "stage"

228 +However, when you do 'git read-tree' with three trees, the "stage"

229 starts out at 1.

230

231 This means that you can do

@@ -241,7 +241,7 @@ branch into the current branch, we use the common ancestor tree

241 as <tree1>, the current branch head as <tree2>, and the other

242 branch head as <tree3>.

243

244 -Furthermore, 'git-read-tree' has special-case logic that says: if you see

244 +Furthermore, 'git read-tree' has special-case logic that says: if you see

245 a file that matches in all respects in the following states, it

246 "collapses" back to "stage0":

247

@@ -257,7 +257,7 @@ a file that matches in all respects in the following states, it

257 - stage 1 and stage 3 are the same and stage 2 is different take

258 stage 2 (we did something while they did nothing)

259

260 -The 'git-write-tree' command refuses to write a nonsensical tree, and it

260 +The 'git write-tree' command refuses to write a nonsensical tree, and it

261 will complain about unmerged entries if it sees a single entry that is not

262 stage 0.

263

@@ -273,7 +273,7 @@ start a 3-way merge with an index file that is already

273 populated. Here is an outline of how the algorithm works:

274

275 - if a file exists in identical format in all three trees, it will

276 - automatically collapse to "merged" state by 'git-read-tree'.

276 + automatically collapse to "merged" state by 'git read-tree'.

277

278 - a file that has _any_ difference what-so-ever in the three trees

279 will stay as separate entries in the index. It's up to "porcelain

@@ -297,8 +297,8 @@ populated. Here is an outline of how the algorithm works:

297 matching "stage1" entry if it exists too. .. all the normal

298 trivial rules ..

299

300 -You would normally use 'git-merge-index' with supplied

301 -'git-merge-one-file' to do this last step. The script updates

300 +You would normally use 'git merge-index' with supplied

301 +'git merge-one-file' to do this last step. The script updates

302 the files in the working tree as it merges each path and at the

303 end of a successful merge.

304

@@ -320,7 +320,7 @@ $ JC=`git rev-parse --verify "HEAD^0"`

320 $ git checkout-index -f -u -a $JC

321 ----------------

322

323 -You do random edits, without running 'git-update-index'. And then

323 +You do random edits, without running 'git update-index'. And then

324 you notice that the tip of your "upstream" tree has advanced

325 since you pulled from him:

326

@@ -346,14 +346,14 @@ your work-in-progress changes, and your work tree would be

346 updated to the result of the merge.

347

348 However, if you have local changes in the working tree that

349 -would be overwritten by this merge, 'git-read-tree' will refuse

349 +would be overwritten by this merge, 'git read-tree' will refuse

350 to run to prevent your changes from being lost.

351

352 In other words, there is no need to worry about what exists only

353 in the working tree. When you have local changes in a part of

354 the project that is not involved in the merge, your changes do

355 not interfere with the merge, and are kept intact. When they

356 -*do* interfere, the merge does not even start ('git-read-tree'

356 +*do* interfere, the merge does not even start ('git read-tree'

357 complains loudly and fails without modifying anything). In such

358 a case, you can simply continue doing what you were in the

359 middle of doing, and when your working tree is ready (i.e. you

Documentation/git-rebase.txt

+19 -19

@@ -17,7 +17,7 @@ SYNOPSIS

18 DESCRIPTION

19 -----------

20 -If <branch> is specified, 'git-rebase' will perform an automatic

20 +If <branch> is specified, 'git rebase' will perform an automatic

21 `git checkout <branch>` before doing anything else. Otherwise

22 it remains on the current branch.

@@ -170,8 +170,8 @@ This is useful if F and G were flawed in some way, or should not be

170 part of topicA. Note that the argument to --onto and the <upstream>

171 parameter can be any valid commit-ish.

172

173 -In case of conflict, 'git-rebase' will stop at the first problematic commit

174 -and leave conflict markers in the tree. You can use 'git-diff' to locate

173 +In case of conflict, 'git rebase' will stop at the first problematic commit

174 +and leave conflict markers in the tree. You can use 'git diff' to locate

175 the markers (<<<<<<) and make edits to resolve the conflict. For each

176 file you edit, you need to tell git that the conflict has been resolved,

177 typically this would be done with

@@ -187,7 +187,7 @@ desired resolution, you can continue the rebasing process with

187 git rebase --continue

188

189

190 -Alternatively, you can undo the 'git-rebase' with

190 +Alternatively, you can undo the 'git rebase' with

191

192

193 git rebase --abort

@@ -238,10 +238,10 @@ other words, the sides are swapped.

238 -s <strategy>::

239 --strategy=<strategy>::

240 Use the given merge strategy.

241 - If there is no `-s` option 'git-merge-recursive' is used

241 + If there is no `-s` option 'git merge-recursive' is used

242 instead. This implies --merge.

243 +

244 -Because 'git-rebase' replays each commit from the working branch

244 +Because 'git rebase' replays each commit from the working branch

245 on top of the <upstream> branch using the given strategy, using

246 the 'ours' strategy simply discards all patches from the <branch>,

247 which makes little sense.

@@ -280,13 +280,13 @@ which makes little sense.

280

281 --ignore-whitespace::

282 --whitespace=<option>::

283 - These flag are passed to the 'git-apply' program

283 + These flag are passed to the 'git apply' program

284 (see linkgit:git-apply[1]) that applies the patch.

285 Incompatible with the --interactive option.

286

287 --committer-date-is-author-date::

288 --ignore-date::

289 - These flags are passed to 'git-am' to easily change the dates

289 + These flags are passed to 'git am' to easily change the dates

290 of the rebased commits (see linkgit:git-am[1]).

291

292 -i::

@@ -313,7 +313,7 @@ include::merge-strategies.txt[]

313 NOTES

314 -----

315

316 -You should understand the implications of using 'git-rebase' on a

316 +You should understand the implications of using 'git rebase' on a

317 repository that you share. See also RECOVERING FROM UPSTREAM REBASE

318 below.

319

@@ -369,12 +369,12 @@ pick fa1afe1 The oneline of the next commit

369 ...

370 -------------------------------------------

371

372 -The oneline descriptions are purely for your pleasure; 'git-rebase' will

372 +The oneline descriptions are purely for your pleasure; 'git rebase' will

373 not look at them but at the commit names ("deadbee" and "fa1afe1" in this

374 example), so do not delete or edit the names.

375

376 By replacing the command "pick" with the command "edit", you can tell

377 -'git-rebase' to stop after applying that commit, so that you can edit

377 +'git rebase' to stop after applying that commit, so that you can edit

378 the files and/or the commit message, amend the commit, and continue

379 rebasing.

380

@@ -386,13 +386,13 @@ If you want to fold two or more commits into one, replace the command

386 commits had different authors, it will attribute the squashed commit to

387 the author of the first commit.

388

389 -'git-rebase' will stop when "pick" has been replaced with "edit" or

389 +'git rebase' will stop when "pick" has been replaced with "edit" or

390 when a command fails due to merge errors. When you are done editing

391 and/or resolving conflicts you can continue with `git rebase --continue`.

392

393 For example, if you want to reorder the last 5 commits, such that what

394 was HEAD~4 becomes the new HEAD. To achieve that, you would call

395 -'git-rebase' like this:

395 +'git rebase' like this:

396

397 ----------------------

398 $ git rebase -i HEAD~5

@@ -422,7 +422,7 @@ SPLITTING COMMITS

422 -----------------

423

424 In interactive mode, you can mark commits with the action "edit". However,

425 -this does not necessarily mean that 'git-rebase' expects the result of this

425 +this does not necessarily mean that 'git rebase' expects the result of this

426 edit to be exactly one commit. Indeed, you can undo the commit, or you can

427 add other commits. This can be used to split a commit into two:

428

@@ -438,7 +438,7 @@ add other commits. This can be used to split a commit into two:

438

439 - Now add the changes to the index that you want to have in the first

440 commit. You can use `git add` (possibly interactively) or

441 - 'git-gui' (or both) to do that.

441 + 'git gui' (or both) to do that.

442

443 - Commit the now-current index with whatever commit message is appropriate

444 now.

@@ -449,7 +449,7 @@ add other commits. This can be used to split a commit into two:

449

450 If you are not absolutely sure that the intermediate revisions are

451 consistent (they compile, pass the testsuite, etc.) you should use

452 -'git-stash' to stash away the not-yet-committed changes

452 +'git stash' to stash away the not-yet-committed changes

453 after each commit, test, and amend the commit if fixes are necessary.

454

455

@@ -524,7 +524,7 @@ Only works if the changes (patch IDs based on the diff contents) on

524 'subsystem' are literally the same before and after the rebase

525 'subsystem' did.

526

527 -In that case, the fix is easy because 'git-rebase' knows to skip

527 +In that case, the fix is easy because 'git rebase' knows to skip

528 changes that are already present in the new upstream. So if you say

529 (assuming you're on 'topic')

530 ------------

@@ -551,12 +551,12 @@ NOTE: While an "easy case recovery" sometimes appears to be successful

551 example, a commit that was removed via `git rebase

552 \--interactive` will be **resurrected**!

553

554 -The idea is to manually tell 'git-rebase' "where the old 'subsystem'

554 +The idea is to manually tell 'git rebase' "where the old 'subsystem'

555 ended and your 'topic' began", that is, what the old merge-base

556 between them was. You will have to find a way to name the last commit

557 of the old 'subsystem', for example:

558

559 -* With the 'subsystem' reflog: after 'git-fetch', the old tip of

559 +* With the 'subsystem' reflog: after 'git fetch', the old tip of

560 'subsystem' is at `subsystem@\{1}`. Subsequent fetches will

561 increase the number. (See linkgit:git-reflog[1].)

562

Documentation/git-receive-pack.txt

+3 -3

@@ -8,15 +8,15 @@ git-receive-pack - Receive what is pushed into the repository

9 SYNOPSIS

10 --------

11 -'git receive-pack' <directory>

11 +'git-receive-pack' <directory>

13 DESCRIPTION

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

15 -Invoked by 'git-send-pack' and updates the repository with the

15 +Invoked by 'git send-pack' and updates the repository with the

16 information fed from the remote end.

18 This command is usually not invoked directly by the end user.

19 -The UI for the protocol is on the 'git-send-pack' side, and the

19 +The UI for the protocol is on the 'git send-pack' side, and the

20 program pair is meant to be used to push updates to remote

21 repository. For pull operations, see linkgit:git-fetch-pack[1].

Documentation/git-reflog.txt

+1 -1

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

60 refs.

61 +

62 This computation involves traversing all the reachable objects, i.e. it

63 -has the same cost as 'git-prune'. Fortunately, once this is run, we

63 +has the same cost as 'git prune'. Fortunately, once this is run, we

64 should not have to ever worry about missing objects, because the current

65 prune and pack-objects know about reflogs and protect objects referred by

66 them.

Documentation/git-remote.txt

+1 -1

@@ -161,7 +161,7 @@ $ git checkout -b nfs linux-nfs/master

161 ...

162 ------------

163

164 -* Imitate 'git-clone' but track only selected branches

164 +* Imitate 'git clone' but track only selected branches

165 +

166 ------------

167 $ mkdir project.git

Documentation/git-repack.txt

+6 -6

@@ -49,16 +49,16 @@ other objects in that pack they already have locally.

49 deleted by way of being left in the old pack and then

50 removed. Instead, the loose unreachable objects

51 will be pruned according to normal expiry rules

52 - with the next 'git-gc' invocation. See linkgit:git-gc[1].

52 + with the next 'git gc' invocation. See linkgit:git-gc[1].

54 -d::

55 After packing, if the newly created packs make some

56 existing packs redundant, remove the redundant packs.

57 - Also run 'git-prune-packed' to remove redundant

57 + Also run 'git prune-packed' to remove redundant

58 loose object files.

60 -l::

61 - Pass the `--local` option to 'git-pack-objects'. See

61 + Pass the `--local` option to 'git pack-objects'. See

62 linkgit:git-pack-objects[1].

64 -f::

@@ -66,12 +66,12 @@ other objects in that pack they already have locally.

66 linkgit:git-pack-objects[1].

68 -q::

69 - Pass the `-q` option to 'git-pack-objects'. See

69 + Pass the `-q` option to 'git pack-objects'. See

70 linkgit:git-pack-objects[1].

72 -n::

73 Do not update the server information with

74 - 'git-update-server-info'. This option skips

74 + 'git update-server-info'. This option skips

75 updating local catalog files needed to publish

76 this repository (or a direct copy of it)

77 over HTTP or FTP. See linkgit:git-update-server-info[1].

@@ -109,7 +109,7 @@ Configuration

109

110 When configuration variable `repack.UseDeltaBaseOffset` is set

111 for the repository, the command passes `--delta-base-offset`

112 -option to 'git-pack-objects'; this typically results in slightly

112 +option to 'git pack-objects'; this typically results in slightly

113 smaller packs, but the generated packs are incompatible with

114 versions of git older than (and including) v1.4.3; do not set

115 the variable in a repository that older version of git needs to

Documentation/git-rerere.txt

+14 -14

@@ -30,14 +30,14 @@ enable this command.

30 COMMANDS

31 --------

33 -Normally, 'git-rerere' is run without arguments or user-intervention.

33 +Normally, 'git rerere' is run without arguments or user-intervention.

34 However, it has several commands that allow it to interact with

35 its working state.

37 'clear'::

39 This resets the metadata used by rerere if a merge resolution is to be

40 -aborted. Calling 'git-am [--skip|--abort]' or 'git-rebase [--skip|--abort]'

40 +aborted. Calling 'git am [--skip|--abort]' or 'git rebase [--skip|--abort]'

41 will automatically invoke this command.

43 'diff'::

@@ -142,32 +142,32 @@ finally ready and merged into the master branch. This merge

142 would require you to resolve the conflict, introduced by the

143 commits marked with `*`. However, this conflict is often the

144 same conflict you resolved when you created the test merge you

145 -blew away. 'git-rerere' helps you resolve this final

145 +blew away. 'git rerere' helps you resolve this final

146 conflicted merge using the information from your earlier hand

147 resolve.

148

149 -Running the 'git-rerere' command immediately after a conflicted

149 +Running the 'git rerere' command immediately after a conflicted

150 automerge records the conflicted working tree files, with the

151 usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in

152 them. Later, after you are done resolving the conflicts,

153 -running 'git-rerere' again will record the resolved state of these

153 +running 'git rerere' again will record the resolved state of these

154 files. Suppose you did this when you created the test merge of

155 master into the topic branch.

156

157 Next time, after seeing the same conflicted automerge,

158 -running 'git-rerere' will perform a three-way merge between the

158 +running 'git rerere' will perform a three-way merge between the

159 earlier conflicted automerge, the earlier manual resolution, and

160 the current conflicted automerge.

161 If this three-way merge resolves cleanly, the result is written

162 out to your working tree file, so you do not have to manually

163 -resolve it. Note that 'git-rerere' leaves the index file alone,

163 +resolve it. Note that 'git rerere' leaves the index file alone,

164 so you still need to do the final sanity checks with `git diff`

165 -(or `git diff -c`) and 'git-add' when you are satisfied.

165 +(or `git diff -c`) and 'git add' when you are satisfied.

166

167 -As a convenience measure, 'git-merge' automatically invokes

168 -'git-rerere' upon exiting with a failed automerge and 'git-rerere'

167 +As a convenience measure, 'git merge' automatically invokes

168 +'git rerere' upon exiting with a failed automerge and 'git rerere'

169 records the hand resolve when it is a new conflict, or reuses the earlier hand

170 -resolve when it is not. 'git-commit' also invokes 'git-rerere'

170 +resolve when it is not. 'git commit' also invokes 'git rerere'

171 when committing a merge result. What this means is that you do

172 not have to do anything special yourself (besides enabling

173 the rerere.enabled config variable).

@@ -177,8 +177,8 @@ resolution is recorded, and it will be reused when you do the

177 actual merge later with the updated master and topic branch, as long

178 as the recorded resolution is still applicable.

179

180 -The information 'git-rerere' records is also used when running

181 -'git-rebase'. After blowing away the test merge and continuing

180 +The information 'git rerere' records is also used when running

181 +'git rebase'. After blowing away the test merge and continuing

182 development on the topic branch:

183

184 ------------

@@ -197,7 +197,7 @@ you could run `git rebase master topic`, to bring yourself

197 up-to-date before your topic is ready to be sent upstream.

198 This would result in falling back to a three-way merge, and it

199 would conflict the same way as the test merge you resolved earlier.

200 -'git-rerere' will be run by 'git-rebase' to help you resolve this

200 +'git rerere' will be run by 'git rebase' to help you resolve this

201 conflict.

202

203

Documentation/git-reset.txt

+1 -1

@@ -39,7 +39,7 @@ OPTIONS

39 --soft::

40 Does not touch the index file nor the working tree at all, but

41 requires them to be in a good order. This leaves all your changed

42 - files "Changes to be committed", as 'git-status' would

42 + files "Changes to be committed", as 'git status' would

43 put it.

45 --hard::

Documentation/git-rev-list.txt

+3 -3

@@ -9,7 +9,7 @@ git-rev-list - Lists commit objects in reverse chronological order

9 SYNOPSIS

10 --------

11 [verse]

12 -'git-rev-list' [ \--max-count=number ]

12 +'git rev-list' [ \--max-count=number ]

13 [ \--skip=number ]

14 [ \--max-age=timestamp ]

15 [ \--min-age=timestamp ]

@@ -93,8 +93,8 @@ between the two operands. The following two commands are equivalent:

93 'rev-list' is a very essential git command, since it

94 provides the ability to build and traverse commit ancestry graphs. For

95 this reason, it has a lot of different options that enables it to be

96 -used by commands as different as 'git-bisect' and

97 -'git-repack'.

96 +used by commands as different as 'git bisect' and

97 +'git repack'.

99 OPTIONS

100 -------

Documentation/git-rev-parse.txt

+17 -17

@@ -15,16 +15,16 @@ DESCRIPTION

16 Many git porcelainish commands take mixture of flags

17 (i.e. parameters that begin with a dash '-') and parameters

18 -meant for the underlying 'git-rev-list' command they use internally

18 +meant for the underlying 'git rev-list' command they use internally

19 and flags and parameters for the other commands they use

20 -downstream of 'git-rev-list'. This command is used to

20 +downstream of 'git rev-list'. This command is used to

21 distinguish between them.

24 OPTIONS

25 -------

26 --parseopt::

27 - Use 'git-rev-parse' in option parsing mode (see PARSEOPT section below).

27 + Use 'git rev-parse' in option parsing mode (see PARSEOPT section below).

29 --keep-dashdash::

30 Only meaningful in `--parseopt` mode. Tells the option parser to echo

@@ -36,17 +36,17 @@ OPTIONS

36 that take options themself.

38 --sq-quote::

39 - Use 'git-rev-parse' in shell quoting mode (see SQ-QUOTE

39 + Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE

40 section below). In contrast to the `--sq` option below, this

41 mode does only quoting. Nothing else is done to command input.

43 --revs-only::

44 Do not output flags and parameters not meant for

45 - 'git-rev-list' command.

45 + 'git rev-list' command.

47 --no-revs::

48 Do not output flags and parameters meant for

49 - 'git-rev-list' command.

49 + 'git rev-list' command.

51 --flags::

52 Do not output non-flag parameters.

@@ -74,7 +74,7 @@ OPTIONS

74 properly quoted for consumption by shell. Useful when

75 you expect your parameter to contain whitespaces and

76 newlines (e.g. when using pickaxe `-S` with

77 - 'git-diff-\*'). In contrast to the `--sq-quote` option,

77 + 'git diff-\*'). In contrast to the `--sq-quote` option,

78 the command input is still interpreted as usual.

80 --not::

@@ -145,12 +145,12 @@ OPTIONS

145 --since=datestring::

146 --after=datestring::

147 Parse the date string, and output the corresponding

148 - --max-age= parameter for 'git-rev-list'.

148 + --max-age= parameter for 'git rev-list'.

149

150 --until=datestring::

151 --before=datestring::

152 Parse the date string, and output the corresponding

153 - --min-age= parameter for 'git-rev-list'.

153 + --min-age= parameter for 'git rev-list'.

154

155 <args>...::

156 Flags and parameters to be parsed.

@@ -171,7 +171,7 @@ blobs contained in a commit.

171 name the same commit object if there are no other object in

172 your repository whose object name starts with dae86e.

173

174 -* An output from 'git-describe'; i.e. a closest tag, optionally

174 +* An output from 'git describe'; i.e. a closest tag, optionally

175 followed by a dash and a number of commits, followed by a dash, a

176 `g`, and an abbreviated object name.

177

@@ -197,13 +197,13 @@ blobs contained in a commit.

197 +

198 HEAD names the commit your changes in the working tree is based on.

199 FETCH_HEAD records the branch you fetched from a remote repository

200 -with your last 'git-fetch' invocation.

200 +with your last 'git fetch' invocation.

201 ORIG_HEAD is created by commands that moves your HEAD in a drastic

202 way, to record the position of the HEAD before their operation, so that

203 you can change the tip of the branch back to the state before you ran

204 them easily.

205 MERGE_HEAD records the commit(s) you are merging into your branch

206 -when you run 'git-merge'.

206 +when you run 'git merge'.

207

208 * A ref followed by the suffix '@' with a date specification

209 enclosed in a brace

@@ -308,7 +308,7 @@ G H I J

308 SPECIFYING RANGES

309 -----------------

310

311 -History traversing commands such as 'git-log' operate on a set

311 +History traversing commands such as 'git log' operate on a set

312 of commits, not just a single commit. To these commands,

313 specifying a single revision with the notation described in the

314 previous section means the set of commits reachable from that

@@ -349,7 +349,7 @@ Here are a handful of examples:

349 PARSEOPT

350 --------

351

352 -In `--parseopt` mode, 'git-rev-parse' helps massaging options to bring to shell

352 +In `--parseopt` mode, 'git rev-parse' helps massaging options to bring to shell

353 scripts the same facilities C builtins have. It works as an option normalizer

354 (e.g. splits single switches aggregate values), a bit like `getopt(1)` does.

355

@@ -361,7 +361,7 @@ usage on the standard error stream, and exits with code 129.

361 Input Format

362 ~~~~~~~~~~~~

363

364 -'git-rev-parse --parseopt' input format is fully text based. It has two parts,

364 +'git rev-parse --parseopt' input format is fully text based. It has two parts,

365 separated by a line that contains only `--`. The lines before the separator

366 (should be more than one) are used for the usage.

367 The lines after the separator describe the options.

@@ -420,13 +420,13 @@ eval `echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?`

420 SQ-QUOTE

421 --------

422

423 -In `--sq-quote` mode, 'git-rev-parse' echoes on the standard output a

423 +In `--sq-quote` mode, 'git rev-parse' echoes on the standard output a

424 single line suitable for `sh(1)` `eval`. This line is made by

425 normalizing the arguments following `--sq-quote`. Nothing other than

426 quoting the arguments is done.

427

428 If you want command input to still be interpreted as usual by

429 -'git-rev-parse' before the output is shell quoted, see the `--sq`

429 +'git rev-parse' before the output is shell quoted, see the `--sq`

430 option.

431

432 Example

Documentation/git-revert.txt

+2 -2

@@ -33,7 +33,7 @@ OPTIONS

34 -e::

35 --edit::

36 - With this option, 'git-revert' will let you edit the commit

36 + With this option, 'git revert' will let you edit the commit

37 message prior to committing the revert. This is the default if

38 you run the command from a terminal.

@@ -54,7 +54,7 @@ See the link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for

54 more details.

56 --no-edit::

57 - With this option, 'git-revert' will not start the commit

57 + With this option, 'git revert' will not start the commit

58 message editor.

60 -n::

Documentation/git-send-pack.txt

+2 -2

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

13 DESCRIPTION

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

15 -Usually you would want to use 'git-push', which is a

15 +Usually you would want to use 'git push', which is a

16 higher-level wrapper of this command, instead. See linkgit:git-push[1].

18 Invokes 'git-receive-pack' on a possibly remote repository, and

@@ -86,7 +86,7 @@ and the destination side (after the colon). The ref to be

86 pushed is determined by finding a match that matches the source

87 side, and where it is pushed is determined by using the

88 destination side. The rules used to match a ref are the same

89 -rules used by 'git-rev-parse' to resolve a symbolic ref

89 +rules used by 'git rev-parse' to resolve a symbolic ref

90 name. See linkgit:git-rev-parse[1].

92 - It is an error if <src> does not match exactly one of the

Documentation/git-sh-setup.txt

+1 -1

@@ -16,7 +16,7 @@ This is not a command the end user would want to run. Ever.

16 This documentation is meant for people who are studying the

17 Porcelain-ish scripts and/or are writing new ones.

19 -The 'git-sh-setup' scriptlet is designed to be sourced (using

19 +The 'git sh-setup' scriptlet is designed to be sourced (using

20 `.`) by other shell scripts to set up some variables pointing at

21 the normal git directories and a few helper shell functions.

Documentation/git-shortlog.txt

+2 -2

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

4 NAME

5 ----

6 -git-shortlog - Summarize 'git-log' output

6 +git-shortlog - Summarize 'git log' output

8 SYNOPSIS

9 --------

@@ -13,7 +13,7 @@ git shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[

14 DESCRIPTION

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

16 -Summarizes 'git-log' output in a format suitable for inclusion

16 +Summarizes 'git log' output in a format suitable for inclusion

17 in release announcements. Each commit will be grouped by author and

18 the first line of the commit message will be shown.

Documentation/git-show-index.txt

+2 -2

@@ -14,10 +14,10 @@ SYNOPSIS

14 DESCRIPTION

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

16 Reads given idx file for packed git archive created with

17 -'git-pack-objects' command, and dumps its contents.

17 +'git pack-objects' command, and dumps its contents.

19 The information it outputs is subset of what you can get from

20 -'git-verify-pack -v'; this command only shows the packfile

20 +'git verify-pack -v'; this command only shows the packfile

21 offset and SHA1 of each object.

Documentation/git-show-ref.txt

+2 -2

@@ -72,7 +72,7 @@ OPTIONS

73 --exclude-existing[=<pattern>]::

75 - Make 'git-show-ref' act as a filter that reads refs from stdin of the

75 + Make 'git show-ref' act as a filter that reads refs from stdin of the

76 form "^(?:<anything>\s)?<refname>(?:\^\{\})?$" and performs the

77 following actions on each:

78 (1) strip "^{}" at the end of line if any;

@@ -135,7 +135,7 @@ When using the '--verify' flag, the command requires an exact path:

135

136 will only match the exact branch called "master".

137

138 -If nothing matches, 'git-show-ref' will return an error code of 1,

138 +If nothing matches, 'git show-ref' will return an error code of 1,

139 and in the case of verification, it will show an error message.

140

141 For scripting, you can ask it to be quiet with the "--quiet" flag, which

Documentation/git-show.txt

+3 -3

@@ -16,16 +16,16 @@ Shows one or more objects (blobs, trees, tags and commits).

17 For commits it shows the log message and textual diff. It also

18 presents the merge commit in a special format as produced by

19 -'git-diff-tree --cc'.

19 +'git diff-tree --cc'.

21 For tags, it shows the tag message and the referenced objects.

23 -For trees, it shows the names (equivalent to 'git-ls-tree'

23 +For trees, it shows the names (equivalent to 'git ls-tree'

24 with \--name-only).

26 For plain blobs, it shows the plain contents.

28 -The command takes options applicable to the 'git-diff-tree' command to

28 +The command takes options applicable to the 'git diff-tree' command to

29 control how the changes the commit introduces are shown.

31 This manual page describes only the most frequently used options.

Documentation/git-stash.txt

+3 -3

@@ -77,7 +77,7 @@ stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation

77 stash@{1}: On master: 9cc0589... Add git-stash

78 ----------------------------------------------------------------

79 +

80 -The command takes options applicable to the 'git-log'

80 +The command takes options applicable to the 'git log'

81 command to control what is shown and how. See linkgit:git-log[1].

83 show [<stash>]::

@@ -85,7 +85,7 @@ show [<stash>]::

85 Show the changes recorded in the stash as a diff between the

86 stashed state and its original parent. When no `<stash>` is given,

87 shows the latest one. By default, the command shows the diffstat, but

88 - it will accept any format known to 'git-diff' (e.g., `git stash show

88 + it will accept any format known to 'git diff' (e.g., `git stash show

89 -p stash@\{1}` to view the second most recent stash in patch form).

91 pop [--index] [-q|--quiet] [<stash>]::

@@ -201,7 +201,7 @@ $ git reset --soft HEAD^

201 # ... continue hacking ...

202 ----------------------------------------------------------------

203 +

204 -You can use 'git-stash' to simplify the above, like this:

204 +You can use 'git stash' to simplify the above, like this:

205 +

206 ----------------------------------------------------------------

207 # ... hack hack hack ...

Documentation/git-status.txt

+1 -1

@@ -17,7 +17,7 @@ current HEAD commit, paths that have differences between the working

17 tree and the index file, and paths in the working tree that are not

18 tracked by git (and are not ignored by linkgit:gitignore[5]). The first

19 are what you _would_ commit by running `git commit`; the second and

20 -third are what you _could_ commit by running 'git-add' before running

20 +third are what you _could_ commit by running 'git add' before running

21 `git commit`.

23 OPTIONS

Documentation/git-submodule.txt

+2 -2

@@ -99,11 +99,11 @@ locate the submodule using the relative URL in .gitmodules.

99 status::

100 Show the status of the submodules. This will print the SHA-1 of the

101 currently checked out commit for each submodule, along with the

102 - submodule path and the output of 'git-describe' for the

102 + submodule path and the output of 'git describe' for the

103 SHA-1. Each SHA-1 will be prefixed with `-` if the submodule is not

104 initialized and `+` if the currently checked out submodule commit

105 does not match the SHA-1 found in the index of the containing

106 - repository. This command is the default command for 'git-submodule'.

106 + repository. This command is the default command for 'git submodule'.

107 +

108 If '--recursive' is specified, this command will recurse into nested

109 submodules, and show their status as well.

Documentation/git-symbolic-ref.txt

+1 -1

@@ -49,7 +49,7 @@ cumbersome. On some platforms, `ln -sf` does not even work as

49 advertised (horrors). Therefore symbolic links are now deprecated

50 and symbolic refs are used by default.

52 -'git-symbolic-ref' will exit with status 0 if the contents of the

52 +'git symbolic-ref' will exit with status 0 if the contents of the

53 symbolic ref were printed correctly, with status 1 if the requested

54 name is not a symbolic ref, or 128 if another error occurs.

Documentation/git-tag.txt

+4 -4

@@ -95,7 +95,7 @@ OPTIONS

96 CONFIGURATION

97 -------------

98 -By default, 'git-tag' in sign-with-default mode (-s) will use your

98 +By default, 'git tag' in sign-with-default mode (-s) will use your

99 committer identity (of the form "Your Name <your@email.address>") to

100 find a key. If you want to use a different default key, you can specify

101 it in the repository configuration as follows:

@@ -131,12 +131,12 @@ and be done with it.

131

132 . The insane thing.

133 You really want to call the new version "X" too, 'even though'

134 -others have already seen the old one. So just use 'git-tag -f'

134 +others have already seen the old one. So just use 'git tag -f'

135 again, as if you hadn't already published the old one.

136

137 However, Git does *not* (and it should not) change tags behind

138 users back. So if somebody already got the old tag, doing a

139 -'git-pull' on your tree shouldn't just make them overwrite the old

139 +'git pull' on your tree shouldn't just make them overwrite the old

140 one.

141

142 If somebody got a release tag from you, you cannot just change

@@ -190,7 +190,7 @@ private anchor point tags from the other person.

190

191 You would notice "please pull" messages on the mailing list says

192 repo URL and branch name alone. This is designed to be easily

193 -cut&pasted to a 'git-fetch' command line:

193 +cut&pasted to a 'git fetch' command line:

194

195 ------------

196 Linus, please pull from

Documentation/git-tar-tree.txt

+3 -3

@@ -12,19 +12,19 @@ SYNOPSIS

13 DESCRIPTION

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

15 -THIS COMMAND IS DEPRECATED. Use 'git-archive' with `--format=tar`

15 +THIS COMMAND IS DEPRECATED. Use 'git archive' with `--format=tar`

16 option instead (and move the <base> argument to `--prefix=base/`).

18 Creates a tar archive containing the tree structure for the named tree.

19 When <base> is specified it is added as a leading path to the files in the

20 generated tar archive.

22 -'git-tar-tree' behaves differently when given a tree ID versus when given

22 +'git tar-tree' behaves differently when given a tree ID versus when given

23 a commit ID or tag ID. In the first case the current time is used as

24 modification time of each file in the archive. In the latter case the

25 commit time as recorded in the referenced commit object is used instead.

26 Additionally the commit ID is stored in a global extended pax header.

27 -It can be extracted using 'git-get-tar-commit-id'.

27 +It can be extracted using 'git get-tar-commit-id'.

29 OPTIONS

30 -------

Documentation/git-update-index.txt

+11 -11

@@ -31,7 +31,7 @@ cleared.

31 See also linkgit:git-add[1] for a more user-friendly way to do some of

32 the most common operations on the index.

34 -The way 'git-update-index' handles files it is told about can be modified

34 +The way 'git update-index' handles files it is told about can be modified

35 using the various options:

37 OPTIONS

@@ -53,7 +53,7 @@ OPTIONS

53 -q::

54 Quiet. If --refresh finds that the index needs an update, the

55 default behavior is to error out. This option makes

56 - 'git-update-index' continue anyway.

56 + 'git update-index' continue anyway.

58 --ignore-submodules::

59 Do not try to update submodules. This option is only respected

@@ -61,7 +61,7 @@ OPTIONS

62 --unmerged::

63 If --refresh finds unmerged changes in the index, the default

64 - behavior is to error out. This option makes 'git-update-index'

64 + behavior is to error out. This option makes 'git update-index'

65 continue anyway.

67 --ignore-missing::

@@ -105,7 +105,7 @@ you will need to handle the situation manually.

105

106 -g::

107 --again::

108 - Runs 'git-update-index' itself on the paths whose index

108 + Runs 'git update-index' itself on the paths whose index

109 entries are different from those from the `HEAD` commit.

110

111 --unresolve::

@@ -123,7 +123,7 @@ you will need to handle the situation manually.

123

124 --replace::

125 By default, when a file `path` exists in the index,

126 - 'git-update-index' refuses an attempt to add `path/file`.

126 + 'git update-index' refuses an attempt to add `path/file`.

127 Similarly if a file `path/file` exists, a file `path`

128 cannot be added. With --replace flag, existing entries

129 that conflict with the entry being added are

@@ -159,7 +159,7 @@ up-to-date for mode/content changes. But what it *does* do is to

159 can refresh the index for a file that hasn't been changed but where

160 the stat entry is out of date.

161

162 -For example, you'd want to do this after doing a 'git-read-tree', to link

162 +For example, you'd want to do this after doing a 'git read-tree', to link

163 up the stat index details with the proper files.

164

165 Using --cacheinfo or --info-only

@@ -200,13 +200,13 @@ back on 3-way merge.

200

201 . mode SP type SP sha1 TAB path

202 +

203 -The second format is to stuff 'git-ls-tree' output

203 +The second format is to stuff 'git ls-tree' output

204 into the index file.

205

206 . mode SP sha1 SP stage TAB path

207 +

208 This format is to put higher order stages into the

209 -index file and matches 'git-ls-files --stage' output.

209 +index file and matches 'git ls-files --stage' output.

210

211 To place a higher stage entry to the index, the path should

212 first be removed by feeding a mode=0 entry for the path, and

@@ -263,8 +263,8 @@ option. To unset, use `--no-assume-unchanged`.

263 The command looks at `core.ignorestat` configuration variable. When

264 this is true, paths updated with `git update-index paths...` and

265 paths updated with other git commands that update both index and

266 -working tree (e.g. 'git-apply --index', 'git-checkout-index -u',

267 -and 'git-read-tree -u') are automatically marked as "assume

266 +working tree (e.g. 'git apply --index', 'git checkout-index -u',

267 +and 'git read-tree -u') are automatically marked as "assume

268 unchanged". Note that "assume unchanged" bit is *not* set if

269 `git update-index --refresh` finds the working tree file matches

270 the index (use `git update-index --really-refresh` if you want

@@ -317,7 +317,7 @@ unreliable, this should be set to 'false' (see linkgit:git-config[1]).

317 This causes the command to ignore differences in file modes recorded

318 in the index and the file mode on the filesystem if they differ only on

319 executable bit. On such an unfortunate filesystem, you may

320 -need to use 'git-update-index --chmod='.

320 +need to use 'git update-index --chmod='.

321

322 Quite similarly, if `core.symlinks` configuration variable is set

323 to 'false' (see linkgit:git-config[1]), symbolic links are checked out

Documentation/git-upload-archive.txt

+2 -2

@@ -12,11 +12,11 @@ SYNOPSIS

13 DESCRIPTION

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

15 -Invoked by 'git-archive --remote' and sends a generated archive to the

15 +Invoked by 'git archive --remote' and sends a generated archive to the

16 other end over the git protocol.

18 This command is usually not invoked directly by the end user. The UI

19 -for the protocol is on the 'git-archive' side, and the program pair

19 +for the protocol is on the 'git archive' side, and the program pair

20 is meant to be used to get an archive from a remote repository.

22 OPTIONS

Documentation/git-upload-pack.txt

+4 -4

@@ -8,17 +8,17 @@ git-upload-pack - Send objects packed back to git-fetch-pack

9 SYNOPSIS

10 --------

11 -'git upload-pack' [--strict] [--timeout=<n>] <directory>

11 +'git-upload-pack' [--strict] [--timeout=<n>] <directory>

13 DESCRIPTION

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

15 -Invoked by 'git-fetch-pack', learns what

15 +Invoked by 'git fetch-pack', learns what

16 objects the other side is missing, and sends them after packing.

18 This command is usually not invoked directly by the end user.

19 -The UI for the protocol is on the 'git-fetch-pack' side, and the

19 +The UI for the protocol is on the 'git fetch-pack' side, and the

20 program pair is meant to be used to pull updates from a remote

21 -repository. For push operations, see 'git-send-pack'.

21 +repository. For push operations, see 'git send-pack'.

24 OPTIONS

Documentation/git-verify-pack.txt

+1 -1

@@ -14,7 +14,7 @@ SYNOPSIS

14 DESCRIPTION

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

16 Reads given idx file for packed git archive created with the

17 -'git-pack-objects' command and verifies idx file and the

17 +'git pack-objects' command and verifies idx file and the

18 corresponding pack file.

20 OPTIONS

Documentation/git-verify-tag.txt

+1 -1

@@ -11,7 +11,7 @@ SYNOPSIS

12 DESCRIPTION

13 -----------

14 -Validates the gpg signature created by 'git-tag'.

14 +Validates the gpg signature created by 'git tag'.

16 OPTIONS

17 -------

Documentation/git-web--browse.txt

+3 -3

@@ -62,7 +62,7 @@ browser.<tool>.path

62 You can explicitly provide a full path to your preferred browser by

63 setting the configuration variable 'browser.<tool>.path'. For example,

64 you can configure the absolute path to firefox by setting

65 -'browser.firefox.path'. Otherwise, 'git-web--browse' assumes the tool

65 +'browser.firefox.path'. Otherwise, 'git web--browse' assumes the tool

66 is available in PATH.

68 browser.<tool>.cmd

@@ -71,7 +71,7 @@ browser.<tool>.cmd

71 When the browser, specified by options or configuration variables, is

72 not among the supported ones, then the corresponding

73 'browser.<tool>.cmd' configuration variable will be looked up. If this

74 -variable exists then 'git-web--browse' will treat the specified tool

74 +variable exists then 'git web--browse' will treat the specified tool

75 as a custom command and will use a shell eval to run the command with

76 the URLs passed as arguments.

@@ -113,7 +113,7 @@ See linkgit:git-config[1] for more information about this.

113 Author

114 ------

115 Written by Christian Couder <chriscool@tuxfamily.org> and the git-list

116 -<git@vger.kernel.org>, based on 'git-mergetool' by Theodore Y. Ts'o.

116 +<git@vger.kernel.org>, based on 'git mergetool' by Theodore Y. Ts'o.

117

118 Documentation

119 -------------

Documentation/git-whatchanged.txt

+2 -2

@@ -13,8 +13,8 @@ SYNOPSIS

13 DESCRIPTION

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

15 Shows commit logs and diff output each commit introduces. The

16 -command internally invokes 'git-rev-list' piped to

17 -'git-diff-tree', and takes command line options for both of

16 +command internally invokes 'git rev-list' piped to

17 +'git diff-tree', and takes command line options for both of

18 these commands.

20 This manual page describes only the most frequently used options.

Documentation/git-write-tree.txt

+4 -4

@@ -17,17 +17,17 @@ tree object is printed to standard output.

18 The index must be in a fully merged state.

20 -Conceptually, 'git-write-tree' sync()s the current index contents

20 +Conceptually, 'git write-tree' sync()s the current index contents

21 into a set of tree files.

22 In order to have that match what is actually in your directory right

23 -now, you need to have done a 'git-update-index' phase before you did the

24 -'git-write-tree'.

23 +now, you need to have done a 'git update-index' phase before you did the

24 +'git write-tree'.

27 OPTIONS

28 -------

29 --missing-ok::

30 - Normally 'git-write-tree' ensures that the objects referenced by the

30 + Normally 'git write-tree' ensures that the objects referenced by the

31 directory exist in the object database. This option disables this

32 check.

Documentation/git.txt

+4 -4

@@ -573,8 +573,8 @@ other

573 linkgit:git-config[1].

574

575 'GIT_SSH'::

576 - If this environment variable is set then 'git-fetch'

577 - and 'git-push' will use this command instead

576 + If this environment variable is set then 'git fetch'

577 + and 'git push' will use this command instead

578 of 'ssh' when they need to connect to a remote system.

579 The '$GIT_SSH' command will be given exactly two arguments:

580 the 'username@host' (or just 'host') from the URL and the

@@ -590,8 +590,8 @@ for further details.

590

591 'GIT_FLUSH'::

592 If this environment variable is set to "1", then commands such

593 - as 'git-blame' (in incremental mode), 'git-rev-list', 'git-log',

594 - and 'git-whatchanged' will force a flush of the output stream

593 + as 'git blame' (in incremental mode), 'git rev-list', 'git log',

594 + and 'git whatchanged' will force a flush of the output stream

595 after each commit-oriented record have been flushed. If this

596 variable is set to "0", the output of these commands will be done

597 using completely buffered I/O. If this environment variable is

Documentation/gitattributes.txt

+6 -6

@@ -88,9 +88,9 @@ Checking-out and checking-in

89 These attributes affect how the contents stored in the

90 repository are copied to the working tree files when commands

91 -such as 'git-checkout' and 'git-merge' run. They also affect how

91 +such as 'git checkout' and 'git merge' run. They also affect how

92 git stores the contents you prepare in the working tree in the

93 -repository upon 'git-add' and 'git-commit'.

93 +repository upon 'git add' and 'git commit'.

95 `crlf`

96 ^^^^^^

@@ -148,16 +148,16 @@ an irreversible conversion. The safety triggers to prevent such

148 a conversion done to the files in the work tree, but there are a

149 few exceptions. Even though...

150

151 -- 'git-add' itself does not touch the files in the work tree, the

151 +- 'git add' itself does not touch the files in the work tree, the

152 next checkout would, so the safety triggers;

153

154 -- 'git-apply' to update a text file with a patch does touch the files

154 +- 'git apply' to update a text file with a patch does touch the files

155 in the work tree, but the operation is about text files and CRLF

156 conversion is about fixing the line ending inconsistencies, so the

157 safety does not trigger;

158

159 -- 'git-diff' itself does not touch the files in the work tree, it is

160 - often run to inspect the changes you intend to next 'git-add'. To

159 +- 'git diff' itself does not touch the files in the work tree, it is

160 + often run to inspect the changes you intend to next 'git add'. To

161 catch potential problems early, safety triggers.

162

163

Documentation/gitcore-tutorial.txt

+80 -80

@@ -44,7 +44,7 @@ to import into git.

44 For our first example, we're going to start a totally new repository from

45 scratch, with no pre-existing files, and we'll call it 'git-tutorial'.

46 To start up, create a subdirectory for it, change into that

47 -subdirectory, and initialize the git infrastructure with 'git-init':

47 +subdirectory, and initialize the git infrastructure with 'git init':

49 ------------------------------------------------

50 $ mkdir git-tutorial

@@ -139,7 +139,7 @@ but to actually check in your hard work, you will have to go through two steps:

139 - commit that index file as an object.

140

141 The first step is trivial: when you want to tell git about any changes

142 -to your working tree, you use the 'git-update-index' program. That

142 +to your working tree, you use the 'git update-index' program. That

143 program normally just takes a list of filenames you want to update, but

144 to avoid trivial mistakes, it refuses to add new entries to the index

145 (or remove existing ones) unless you explicitly tell it that you're

@@ -173,14 +173,14 @@ and see two files:

173 which correspond with the objects with names of `557db...` and

174 `f24c7...` respectively.

175

176 -If you want to, you can use 'git-cat-file' to look at those objects, but

176 +If you want to, you can use 'git cat-file' to look at those objects, but

177 you'll have to use the object name, not the filename of the object:

178

179 ----------------

180 $ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238

181 ----------------

182

183 -where the `-t` tells 'git-cat-file' to tell you what the "type" of the

183 +where the `-t` tells 'git cat-file' to tell you what the "type" of the

184 object is. git will tell you that you have a "blob" object (i.e., just a

185 regular file), and you can see the contents with

186

@@ -205,7 +205,7 @@ hexadecimal digits in most places.

205 Anyway, as we mentioned previously, you normally never actually take a

206 look at the objects themselves, and typing long 40-character hex

207 names is not something you'd normally want to do. The above digression

208 -was just to show that 'git-update-index' did something magical, and

208 +was just to show that 'git update-index' did something magical, and

209 actually saved away the contents of your files into the git object

210 database.

211

@@ -228,7 +228,7 @@ $ echo "It's a new day for git" >>hello

228

229 and you can now, since you told git about the previous state of `hello`, ask

230 git what has changed in the tree compared to your old index, using the

231 -'git-diff-files' command:

231 +'git diff-files' command:

232

233 ------------

234 $ git diff-files

@@ -239,7 +239,7 @@ version of a 'diff', but that internal version really just tells you

239 that it has noticed that "hello" has been modified, and that the old object

240 contents it had have been replaced with something else.

241

242 -To make it readable, we can tell 'git-diff-files' to output the

242 +To make it readable, we can tell 'git diff-files' to output the

243 differences as a patch, using the `-p` flag:

244

245 ------------

@@ -255,7 +255,7 @@ index 557db03..263414f 100644

255

256 i.e. the diff of the change we caused by adding another line to `hello`.

257

258 -In other words, 'git-diff-files' always shows us the difference between

258 +In other words, 'git diff-files' always shows us the difference between

259 what is recorded in the index, and what is currently in the working

260 tree. That's very useful.

261

@@ -283,7 +283,7 @@ that in two phases: creating a 'tree' object, and committing that 'tree'

283 object as a 'commit' object together with an explanation of what the

284 tree was all about, along with information of how we came to that state.

285

286 -Creating a tree object is trivial, and is done with 'git-write-tree'.

286 +Creating a tree object is trivial, and is done with 'git write-tree'.

287 There are no options or other input: `git write-tree` will take the

288 current index state, and write an object that describes that whole

289 index. In other words, we're now tying together all the different

@@ -307,23 +307,23 @@ is not a "blob" object, but a "tree" object (you can also use

307 `git cat-file` to actually output the raw object contents, but you'll see

308 mainly a binary mess, so that's less interesting).

309

310 -However -- normally you'd never use 'git-write-tree' on its own, because

310 +However -- normally you'd never use 'git write-tree' on its own, because

311 normally you always commit a tree into a commit object using the

312 -'git-commit-tree' command. In fact, it's easier to not actually use

313 -'git-write-tree' on its own at all, but to just pass its result in as an

314 -argument to 'git-commit-tree'.

312 +'git commit-tree' command. In fact, it's easier to not actually use

313 +'git write-tree' on its own at all, but to just pass its result in as an

314 +argument to 'git commit-tree'.

315

316 -'git-commit-tree' normally takes several arguments -- it wants to know

316 +'git commit-tree' normally takes several arguments -- it wants to know

317 what the 'parent' of a commit was, but since this is the first commit

318 ever in this new repository, and it has no parents, we only need to pass in

319 -the object name of the tree. However, 'git-commit-tree' also wants to get a

319 +the object name of the tree. However, 'git commit-tree' also wants to get a

320 commit message on its standard input, and it will write out the resulting

321 object name for the commit to its standard output.

322

323 And this is where we create the `.git/refs/heads/master` file

324 which is pointed at by `HEAD`. This file is supposed to contain

325 the reference to the top-of-tree of the master branch, and since

326 -that's exactly what 'git-commit-tree' spits out, we can do this

326 +that's exactly what 'git commit-tree' spits out, we can do this

327 all with a sequence of simple shell commands:

328

329 ------------------------------------------------

@@ -345,11 +345,11 @@ instead, and it would have done the above magic scripting for you.

345 Making a change

346 ---------------

347

348 -Remember how we did the 'git-update-index' on file `hello` and then we

348 +Remember how we did the 'git update-index' on file `hello` and then we

349 changed `hello` afterward, and could compare the new state of `hello` with the

350 state we saved in the index file?

351

352 -Further, remember how I said that 'git-write-tree' writes the contents

352 +Further, remember how I said that 'git write-tree' writes the contents

353 of the *index* file to the tree, and thus what we just committed was in

354 fact the *original* contents of the file `hello`, not the new ones. We did

355 that on purpose, to show the difference between the index state, and the

@@ -360,12 +360,12 @@ As before, if we do `git diff-files -p` in our git-tutorial project,

360 we'll still see the same difference we saw last time: the index file

361 hasn't changed by the act of committing anything. However, now that we

362 have committed something, we can also learn to use a new command:

363 -'git-diff-index'.

363 +'git diff-index'.

364

365 -Unlike 'git-diff-files', which showed the difference between the index

366 -file and the working tree, 'git-diff-index' shows the differences

365 +Unlike 'git diff-files', which showed the difference between the index

366 +file and the working tree, 'git diff-index' shows the differences

367 between a committed *tree* and either the index file or the working

368 -tree. In other words, 'git-diff-index' wants a tree to be diffed

368 +tree. In other words, 'git diff-index' wants a tree to be diffed

369 against, and before we did the commit, we couldn't do that, because we

370 didn't have anything to diff against.

371

@@ -375,7 +375,7 @@ But now we can do

375 $ git diff-index -p HEAD

376 ----------------

377

378 -(where `-p` has the same meaning as it did in 'git-diff-files'), and it

378 +(where `-p` has the same meaning as it did in 'git diff-files'), and it

379 will show us the same difference, but for a totally different reason.

380 Now we're comparing the working tree not against the index file,

381 but against the tree we just wrote. It just so happens that those two

@@ -390,7 +390,7 @@ $ git diff HEAD

390

391 which ends up doing the above for you.

392

393 -In other words, 'git-diff-index' normally compares a tree against the

393 +In other words, 'git diff-index' normally compares a tree against the

394 working tree, but when given the `\--cached` flag, it is told to

395 instead compare against just the index cache contents, and ignore the

396 current working tree state entirely. Since we just wrote the index

@@ -399,7 +399,7 @@ an empty set of differences, and that's exactly what it does.

399

400 [NOTE]

401 ================

402 -'git-diff-index' really always uses the index for its

402 +'git diff-index' really always uses the index for its

403 comparisons, and saying that it compares a tree against the working

404 tree is thus not strictly accurate. In particular, the list of

405 files to compare (the "meta-data") *always* comes from the index file,

@@ -428,11 +428,11 @@ $ git update-index hello

428 (note how we didn't need the `\--add` flag this time, since git knew

429 about the file already).

430

431 -Note what happens to the different 'git-diff-\*' versions here. After

431 +Note what happens to the different 'git diff-\*' versions here. After

432 we've updated `hello` in the index, `git diff-files -p` now shows no

433 differences, but `git diff-index -p HEAD` still *does* show that the

434 current state is different from the state we committed. In fact, now

435 -'git-diff-index' shows the same difference whether we use the `--cached`

435 +'git diff-index' shows the same difference whether we use the `--cached`

436 flag or not, since now the index is coherent with the working tree.

437

438 Now, since we've updated `hello` in the index, we can commit the new

@@ -460,7 +460,7 @@ You've now made your first real git commit. And if you're interested in

460 looking at what `git commit` really does, feel free to investigate:

461 it's a few very simple shell scripts to generate the helpful (?) commit

462 message headers, and a few one-liners that actually do the

463 -commit itself ('git-commit').

463 +commit itself ('git commit').

464

465

466 Inspecting Changes

@@ -468,9 +468,9 @@ Inspecting Changes

468

469 While creating changes is useful, it's even more useful if you can tell

470 later what changed. The most useful command for this is another of the

471 -'diff' family, namely 'git-diff-tree'.

471 +'diff' family, namely 'git diff-tree'.

472

473 -'git-diff-tree' can be given two arbitrary trees, and it will tell you the

473 +'git diff-tree' can be given two arbitrary trees, and it will tell you the

474 differences between them. Perhaps even more commonly, though, you can

475 give it just a single commit object, and it will figure out the parent

476 of that commit itself, and show the difference directly. Thus, to get

@@ -518,15 +518,15 @@ various diff-\* commands compare things.

518 +-----------+

519 ============

520

521 -More interestingly, you can also give 'git-diff-tree' the `--pretty` flag,

521 +More interestingly, you can also give 'git diff-tree' the `--pretty` flag,

522 which tells it to also show the commit message and author and date of the

523 commit, and you can tell it to show a whole series of diffs.

524 Alternatively, you can tell it to be "silent", and not show the diffs at

525 all, but just show the actual commit message.

526

527 -In fact, together with the 'git-rev-list' program (which generates a

528 -list of revisions), 'git-diff-tree' ends up being a veritable fount of

529 -changes. A trivial (but very useful) script called 'git-whatchanged' is

527 +In fact, together with the 'git rev-list' program (which generates a

528 +list of revisions), 'git diff-tree' ends up being a veritable fount of

529 +changes. A trivial (but very useful) script called 'git whatchanged' is

530 included with git which does exactly this, and shows a log of recent

531 activities.

532

@@ -553,14 +553,14 @@ When using the above two commands, the initial commit will be shown.

553 If this is a problem because it is huge, you can hide it by setting

554 the log.showroot configuration variable to false. Having this, you

555 can still show it for each command just adding the `\--root` option,

556 -which is a flag for 'git-diff-tree' accepted by both commands.

556 +which is a flag for 'git diff-tree' accepted by both commands.

557

558 With that, you should now be having some inkling of what git does, and

559 can explore on your own.

560

561 [NOTE]

562 Most likely, you are not directly using the core

563 -git Plumbing commands, but using Porcelain such as 'git-add', `git-rm'

563 +git Plumbing commands, but using Porcelain such as 'git add', `git-rm'

564 and `git-commit'.

565

566

@@ -595,7 +595,7 @@ pointer to the state you want to tag, but also a small tag name and

595 message, along with optionally a PGP signature that says that yes,

596 you really did

597 that tag. You create these annotated tags with either the `-a` or

598 -`-s` flag to 'git-tag':

598 +`-s` flag to 'git tag':

599

600 ----------------

601 $ git tag -s <tagname>

@@ -642,7 +642,7 @@ and it will be gone. There's no external repository, and there's no

642 history outside the project you created.

643

644 - if you want to move or duplicate a git repository, you can do so. There

645 - is 'git-clone' command, but if all you want to do is just to

645 + is 'git clone' command, but if all you want to do is just to

646 create a copy of your repository (with all the full history that

647 went along with it), you can do so with a regular

648 `cp -a git-tutorial new-git-tutorial`.

@@ -666,7 +666,7 @@ When copying a remote repository, you'll want to at a minimum update the

666 index cache when you do this, and especially with other peoples'

667 repositories you often want to make sure that the index cache is in some

668 known state (you don't know *what* they've done and not yet checked in),

669 -so usually you'll precede the 'git-update-index' with a

669 +so usually you'll precede the 'git update-index' with a

670

671 ----------------

672 $ git read-tree --reset HEAD

@@ -674,7 +674,7 @@ $ git update-index --refresh

674 ----------------

675

676 which will force a total index re-build from the tree pointed to by `HEAD`.

677 -It resets the index contents to `HEAD`, and then the 'git-update-index'

677 +It resets the index contents to `HEAD`, and then the 'git update-index'

678 makes sure to match up all index entries with the checked-out files.

679 If the original repository had uncommitted changes in its

680 working tree, `git update-index --refresh` notices them and

@@ -689,8 +689,8 @@ $ git reset

689 and in fact a lot of the common git command combinations can be scripted

690 with the `git xyz` interfaces. You can learn things by just looking

691 at what the various git scripts do. For example, `git reset` used to be

692 -the above two lines implemented in 'git-reset', but some things like

693 -'git-status' and 'git-commit' are slightly more complex scripts around

692 +the above two lines implemented in 'git reset', but some things like

693 +'git status' and 'git commit' are slightly more complex scripts around

694 the basic git commands.

695

696 Many (most?) public remote repositories will not contain any of

@@ -729,7 +729,7 @@ where the `-u` flag means that you want the checkout to keep the index

729 up-to-date (so that you don't have to refresh it afterward), and the

730 `-a` flag means "check out all files" (if you have a stale copy or an

731 older version of a checked out tree you may also need to add the `-f`

732 -flag first, to tell 'git-checkout-index' to *force* overwriting of any old

732 +flag first, to tell 'git checkout-index' to *force* overwriting of any old

733 files).

734

735 Again, this can all be simplified with

@@ -776,7 +776,7 @@ to it.

776 ================================================

777 If you make the decision to start your new branch at some

778 other point in the history than the current `HEAD`, you can do so by

779 -just telling 'git-checkout' what the base of the checkout would be.

779 +just telling 'git checkout' what the base of the checkout would be.

780 In other words, if you have an earlier tag or branch, you'd just do

781

782 ------------

@@ -819,7 +819,7 @@ $ git branch <branchname> [startingpoint]

819

820 which will simply _create_ the branch, but will not do anything further.

821 You can then later -- once you decide that you want to actually develop

822 -on that branch -- switch to that branch with a regular 'git-checkout'

822 +on that branch -- switch to that branch with a regular 'git checkout'

823 with the branchname as the argument.

824

825

@@ -881,7 +881,7 @@ source.

881 Anyway, let's exit 'gitk' (`^Q` or the File menu), and decide that we want

882 to merge the work we did on the `mybranch` branch into the `master`

883 branch (which is currently our `HEAD` too). To do that, there's a nice

884 -script called 'git-merge', which wants to know which branches you want

884 +script called 'git merge', which wants to know which branches you want

885 to resolve and what the merge is all about:

886

887 ------------

@@ -925,7 +925,7 @@ $ git commit -i hello

925

926 which will very loudly warn you that you're now committing a merge

927 (which is correct, so never mind), and you can write a small merge

928 -message about your adventures in 'git-merge'-land.

928 +message about your adventures in 'git merge'-land.

929

930 After you're done, start up `gitk \--all` to see graphically what the

931 history looks like. Notice that `mybranch` still exists, and you can

@@ -967,21 +967,21 @@ branch head. Please see linkgit:git-rev-parse[1] if you want to

967 see more complex cases.

968

969 [NOTE]

970 -Without the '--more=1' option, 'git-show-branch' would not output the

970 +Without the '--more=1' option, 'git show-branch' would not output the

971 '[master^]' commit, as '[mybranch]' commit is a common ancestor of

972 both 'master' and 'mybranch' tips. Please see linkgit:git-show-branch[1]

973 for details.

974

975 [NOTE]

976 If there were more commits on the 'master' branch after the merge, the

977 -merge commit itself would not be shown by 'git-show-branch' by

977 +merge commit itself would not be shown by 'git show-branch' by

978 default. You would need to provide '--sparse' option to make the

979 merge commit visible in this case.

980

981 Now, let's pretend you are the one who did all the work in

982 `mybranch`, and the fruit of your hard work has finally been merged

983 to the `master` branch. Let's go back to `mybranch`, and run

984 -'git-merge' to get the "upstream changes" back to your branch.

984 +'git merge' to get the "upstream changes" back to your branch.

985

986 ------------

987 $ git checkout mybranch

@@ -1023,12 +1023,12 @@ Merging external work

1023 It's usually much more common that you merge with somebody else than

1024 merging with your own branches, so it's worth pointing out that git

1025 makes that very easy too, and in fact, it's not that different from

1026 -doing a 'git-merge'. In fact, a remote merge ends up being nothing

1026 +doing a 'git merge'. In fact, a remote merge ends up being nothing

1027 more than "fetch the work from a remote repository into a temporary tag"

1028 -followed by a 'git-merge'.

1028 +followed by a 'git merge'.

1029

1030 Fetching from a remote repository is done by, unsurprisingly,

1031 -'git-fetch':

1031 +'git fetch':

1032

1033 ----------------

1034 $ git fetch <remote-repository>

@@ -1095,7 +1095,7 @@ The 'commit walkers' are sometimes also called 'dumb

1095 transports', because they do not require any git aware smart

1096 server like git Native transport does. Any stock HTTP server

1097 that does not even support directory index would suffice. But

1098 -you must prepare your repository with 'git-update-server-info'

1098 +you must prepare your repository with 'git update-server-info'

1099 to help dumb transport downloaders.

1100

1101 Once you fetch from the remote repository, you `merge` that

@@ -1115,7 +1115,7 @@ argument.

1115 [NOTE]

1116 You could do without using any branches at all, by

1117 keeping as many local repositories as you would like to have

1118 -branches, and merging between them with 'git-pull', just like

1118 +branches, and merging between them with 'git pull', just like

1119 you merge between branches. The advantage of this approach is

1120 that it lets you keep a set of files for each `branch` checked

1121 out and you may find it easier to switch back and forth if you

@@ -1132,7 +1132,7 @@ like this:

1132 $ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/

1133 ------------------------------------------------

1134

1135 -and use the "linus" keyword with 'git-pull' instead of the full URL.

1135 +and use the "linus" keyword with 'git pull' instead of the full URL.

1136

1137 Examples.

1138

@@ -1168,7 +1168,7 @@ $ git show-branch --more=2 master mybranch

1168 +* [master^] Some fun.

1169 ------------

1170

1171 -Remember, before running 'git-merge', our `master` head was at

1171 +Remember, before running 'git merge', our `master` head was at

1172 "Some fun." commit, while our `mybranch` head was at "Some

1173 work." commit.

1174

@@ -1195,7 +1195,7 @@ Now we are ready to experiment with the merge by hand.

1195

1196 `git merge` command, when merging two branches, uses 3-way merge

1197 algorithm. First, it finds the common ancestor between them.

1198 -The command it uses is 'git-merge-base':

1198 +The command it uses is 'git merge-base':

1199

1200 ------------

1201 $ mb=$(git merge-base HEAD mybranch)

@@ -1219,7 +1219,7 @@ this:

1219 $ git read-tree -m -u $mb HEAD mybranch

1220 ------------

1221

1222 -This is the same 'git-read-tree' command we have already seen,

1222 +This is the same 'git read-tree' command we have already seen,

1223 but it takes three trees, unlike previous examples. This reads

1224 the contents of each tree into different 'stage' in the index

1225 file (the first tree goes to stage 1, the second to stage 2,

@@ -1260,8 +1260,8 @@ $ git ls-files --unmerged

1260

1261 The next step of merging is to merge these three versions of the

1262 file, using 3-way merge. This is done by giving

1263 -'git-merge-one-file' command as one of the arguments to

1264 -'git-merge-index' command:

1263 +'git merge-one-file' command as one of the arguments to

1264 +'git merge-index' command:

1265

1266 ------------

1267 $ git merge-index git-merge-one-file hello

@@ -1270,7 +1270,7 @@ ERROR: Merge conflict in hello

1270 fatal: merge program failed

1271 ------------

1272

1273 -'git-merge-one-file' script is called with parameters to

1273 +'git merge-one-file' script is called with parameters to

1274 describe those three versions, and is responsible to leave the

1275 merge results in the working tree.

1276 It is a fairly straightforward shell script, and

@@ -1289,9 +1289,9 @@ $ git ls-files --stage

1289 ------------

1290

1291 This is the state of the index file and the working file after

1292 -'git-merge' returns control back to you, leaving the conflicting

1292 +'git merge' returns control back to you, leaving the conflicting

1293 merge for you to resolve. Notice that the path `hello` is still

1294 -unmerged, and what you see with 'git-diff' at this point is

1294 +unmerged, and what you see with 'git diff' at this point is

1295 differences since stage 2 (i.e. your version).

1296

1297

@@ -1328,8 +1328,8 @@ into it later. Obviously, this repository creation needs to be

1328 done only once.

1329

1330 [NOTE]

1331 -'git-push' uses a pair of commands,

1332 -'git-send-pack' on your local machine, and 'git-receive-pack'

1331 +'git push' uses a pair of commands,

1332 +'git send-pack' on your local machine, and 'git-receive-pack'

1333 on the remote machine. The communication between the two over

1334 the network internally uses an SSH connection.

1335

@@ -1344,7 +1344,7 @@ $ mkdir my-git.git

1344 ------------

1345

1346 Then, make that directory into a git repository by running

1347 -'git-init', but this time, since its name is not the usual

1347 +'git init', but this time, since its name is not the usual

1348 `.git`, we do things slightly differently:

1349

1350 ------------

@@ -1407,7 +1407,7 @@ $ git repack

1407

1408 will do it for you. If you followed the tutorial examples, you

1409 would have accumulated about 17 objects in `.git/objects/??/`

1410 -directories by now. 'git-repack' tells you how many objects it

1410 +directories by now. 'git repack' tells you how many objects it

1411 packed, and stores the packed file in `.git/objects/pack`

1412 directory.

1413

@@ -1420,7 +1420,7 @@ them together. The former holds all the data from the objects

1420 in the pack, and the latter holds the index for random

1421 access.

1422

1423 -If you are paranoid, running 'git-verify-pack' command would

1423 +If you are paranoid, running 'git verify-pack' command would

1424 detect if you have a corrupt pack, but do not worry too much.

1425 Our programs are always perfect ;-).

1426

@@ -1487,17 +1487,17 @@ If other people are pulling from your repository over dumb

1487 transport protocols (HTTP), you need to keep this repository

1488 'dumb transport friendly'. After `git init`,

1489 `$GIT_DIR/hooks/post-update.sample` copied from the standard templates

1490 -would contain a call to 'git-update-server-info'

1490 +would contain a call to 'git update-server-info'

1491 but you need to manually enable the hook with

1492 `mv post-update.sample post-update`. This makes sure

1493 -'git-update-server-info' keeps the necessary files up-to-date.

1493 +'git update-server-info' keeps the necessary files up-to-date.

1494

1495 3. Push into the public repository from your primary

1496 repository.

1497

1498 -4. 'git-repack' the public repository. This establishes a big

1498 +4. 'git repack' the public repository. This establishes a big

1499 pack that contains the initial set of objects as the

1500 - baseline, and possibly 'git-prune' if the transport

1500 + baseline, and possibly 'git prune' if the transport

1501 used for pulling from your repository supports packed

1502 repositories.

1503

@@ -1511,14 +1511,14 @@ You can repack this private repository whenever you feel like.

1511 6. Push your changes to the public repository, and announce it

1512 to the public.

1513

1514 -7. Every once in a while, 'git-repack' the public repository.

1514 +7. Every once in a while, 'git repack' the public repository.

1515 Go back to step 5. and continue working.

1516

1517

1518 A recommended work cycle for a "subsystem maintainer" who works

1519 on that project and has an own "public repository" goes like this:

1520

1521 -1. Prepare your work repository, by 'git-clone' the public

1521 +1. Prepare your work repository, by 'git clone' the public

1522 repository of the "project lead". The URL used for the

1523 initial cloning is stored in the remote.origin.url

1524 configuration variable.

@@ -1533,7 +1533,7 @@ on that project and has an own "public repository" goes like this:

1533 point at the repository you are borrowing from.

1534

1535 4. Push into the public repository from your primary

1536 - repository. Run 'git-repack', and possibly 'git-prune' if the

1536 + repository. Run 'git repack', and possibly 'git prune' if the

1537 transport used for pulling from your repository supports

1538 packed repositories.

1539

@@ -1550,7 +1550,7 @@ like.

1550 "project lead" and possibly your "sub-subsystem

1551 maintainers" to pull from it.

1552

1553 -7. Every once in a while, 'git-repack' the public repository.

1553 +7. Every once in a while, 'git repack' the public repository.

1554 Go back to step 5. and continue working.

1555

1556

@@ -1558,7 +1558,7 @@ A recommended work cycle for an "individual developer" who does

1558 not have a "public" repository is somewhat different. It goes

1559 like this:

1560

1561 -1. Prepare your work repository, by 'git-clone' the public

1561 +1. Prepare your work repository, by 'git clone' the public

1562 repository of the "project lead" (or a "subsystem

1563 maintainer", if you work on a subsystem). The URL used for

1564 the initial cloning is stored in the remote.origin.url

@@ -1656,8 +1656,8 @@ $ git reset --hard master~2

1656 ------------

1657

1658 You can make sure `git show-branch` matches the state before

1659 -those two 'git-merge' you just did. Then, instead of running

1660 -two 'git-merge' commands in a row, you would merge these two

1659 +those two 'git merge' you just did. Then, instead of running

1660 +two 'git merge' commands in a row, you would merge these two

1661 branch heads (this is known as 'making an Octopus'):

1662

1663 ------------

Documentation/gitcvs-migration.txt

+5 -5

@@ -47,25 +47,25 @@ them first before running git pull.

47 [NOTE]

48 ================================

49 The 'pull' command knows where to get updates from because of certain

50 -configuration variables that were set by the first 'git-clone'

50 +configuration variables that were set by the first 'git clone'

51 command; see `git config -l` and the linkgit:git-config[1] man

52 page for details.

53 ================================

55 You can update the shared repository with your changes by first committing

56 -your changes, and then using the 'git-push' command:

56 +your changes, and then using the 'git push' command:

58 ------------------------------------------------

59 $ git push origin master

60 ------------------------------------------------

62 to "push" those commits to the shared repository. If someone else has

63 -updated the repository more recently, 'git-push', like 'cvs commit', will

63 +updated the repository more recently, 'git push', like 'cvs commit', will

64 complain, in which case you must pull any changes before attempting the

65 push again.

67 -In the 'git-push' command above we specify the name of the remote branch

68 -to update (`master`). If we leave that out, 'git-push' tries to update

67 +In the 'git push' command above we specify the name of the remote branch

68 +to update (`master`). If we leave that out, 'git push' tries to update

69 any branches in the remote repository that have the same name as a branch

70 in the local repository. So the last 'push' can be done with either of:

Documentation/gitdiffcore.txt

+13 -13

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

12 DESCRIPTION

13 -----------

15 -The diff commands 'git-diff-index', 'git-diff-files', and 'git-diff-tree'

15 +The diff commands 'git diff-index', 'git diff-files', and 'git diff-tree'

16 can be told to manipulate differences they find in

17 unconventional ways before showing 'diff' output. The manipulation

18 is collectively called "diffcore transformation". This short note

@@ -23,18 +23,18 @@ that is easier to understand than the conventional kind.

23 The chain of operation

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

26 -The 'git-diff-{asterisk}' family works by first comparing two sets of

26 +The 'git diff-{asterisk}' family works by first comparing two sets of

27 files:

29 - - 'git-diff-index' compares contents of a "tree" object and the

29 + - 'git diff-index' compares contents of a "tree" object and the

30 working directory (when '\--cached' flag is not used) or a

31 "tree" object and the index file (when '\--cached' flag is

32 used);

34 - - 'git-diff-files' compares contents of the index file and the

34 + - 'git diff-files' compares contents of the index file and the

35 working directory;

37 - - 'git-diff-tree' compares contents of two "tree" objects;

37 + - 'git diff-tree' compares contents of two "tree" objects;

39 In all of these cases, the commands themselves first optionally limit

40 the two sets of files by any pathspecs given on their command-lines,

@@ -74,12 +74,12 @@ into another list. There are currently 5 such transformations:

74 - diffcore-pickaxe

75 - diffcore-order

77 -These are applied in sequence. The set of filepairs 'git-diff-{asterisk}'

77 +These are applied in sequence. The set of filepairs 'git diff-{asterisk}'

78 commands find are used as the input to diffcore-break, and

79 the output from diffcore-break is used as the input to the

80 next transformation. The final result is then passed to the

81 output routine and generates either diff-raw format (see Output

82 -format sections of the manual for 'git-diff-{asterisk}' commands) or

82 +format sections of the manual for 'git diff-{asterisk}' commands) or

83 diff-patch format.

@@ -87,7 +87,7 @@ diffcore-break: For Splitting Up "Complete Rewrites"

87 ----------------------------------------------------

89 The second transformation in the chain is diffcore-break, and is

90 -controlled by the -B option to the 'git-diff-{asterisk}' commands. This is

90 +controlled by the -B option to the 'git diff-{asterisk}' commands. This is

91 used to detect a filepair that represents "complete rewrite" and

92 break such filepair into two filepairs that represent delete and

93 create. E.g. If the input contained this filepair:

@@ -123,7 +123,7 @@ diffcore-rename: For Detection Renames and Copies

123

124 This transformation is used to detect renames and copies, and is

125 controlled by the -M option (to detect renames) and the -C option

126 -(to detect copies as well) to the 'git-diff-{asterisk}' commands. If the

126 +(to detect copies as well) to the 'git diff-{asterisk}' commands. If the

127 input contained these filepairs:

128

129 ------------------------------------------------

@@ -168,11 +168,11 @@ number after the "-M" or "-C" option (e.g. "-M8" to tell it to use

168 8/10 = 80%).

169

170 Note. When the "-C" option is used with `\--find-copies-harder`

171 -option, 'git-diff-{asterisk}' commands feed unmodified filepairs to

171 +option, 'git diff-{asterisk}' commands feed unmodified filepairs to

172 diffcore mechanism as well as modified ones. This lets the copy

173 detector consider unmodified files as copy source candidates at

174 the expense of making it slower. Without `\--find-copies-harder`,

175 -'git-diff-{asterisk}' commands can detect copies only if the file that was

175 +'git diff-{asterisk}' commands can detect copies only if the file that was

176 copied happened to have been modified in the same changeset.

177

178

@@ -223,7 +223,7 @@ diffcore-pickaxe: For Detecting Addition/Deletion of Specified String

223

224 This transformation is used to find filepairs that represent

225 changes that touch a specified string, and is controlled by the

226 --S option and the `\--pickaxe-all` option to the 'git-diff-{asterisk}'

226 +-S option and the `\--pickaxe-all` option to the 'git diff-{asterisk}'

227 commands.

228

229 When diffcore-pickaxe is in use, it checks if there are

@@ -246,7 +246,7 @@ diffcore-order: For Sorting the Output Based on Filenames

246

247 This is used to reorder the filepairs according to the user's

248 (or project's) taste, and is controlled by the -O option to the

249 -'git-diff-{asterisk}' commands.

249 +'git diff-{asterisk}' commands.

250

251 This takes a text file each of whose lines is a shell glob

252 pattern. Filepairs that match a glob pattern on an earlier line

Documentation/githooks.txt

+32 -32

@@ -15,7 +15,7 @@ DESCRIPTION

16 Hooks are little scripts you can place in `$GIT_DIR/hooks`

17 directory to trigger action at certain points. When

18 -'git-init' is run, a handful of example hooks are copied into the

18 +'git init' is run, a handful of example hooks are copied into the

19 `hooks` directory of the new repository, but by default they are

20 all disabled. To enable a hook, rename it by removing its `.sample`

21 suffix.

@@ -32,10 +32,10 @@ HOOKS

32 applypatch-msg

33 ~~~~~~~~~~~~~~

35 -This hook is invoked by 'git-am' script. It takes a single

35 +This hook is invoked by 'git am' script. It takes a single

36 parameter, the name of the file that holds the proposed commit

37 log message. Exiting with non-zero status causes

38 -'git-am' to abort before applying the patch.

38 +'git am' to abort before applying the patch.

40 The hook is allowed to edit the message file in place, and can

41 be used to normalize the message into some project standard

@@ -48,7 +48,7 @@ The default 'applypatch-msg' hook, when enabled, runs the

48 pre-applypatch

49 ~~~~~~~~~~~~~~

51 -This hook is invoked by 'git-am'. It takes no parameter, and is

51 +This hook is invoked by 'git am'. It takes no parameter, and is

52 invoked after the patch is applied, but before a commit is made.

54 If it exits with non-zero status, then the working tree will not be

@@ -63,33 +63,33 @@ The default 'pre-applypatch' hook, when enabled, runs the

63 post-applypatch

64 ~~~~~~~~~~~~~~~

66 -This hook is invoked by 'git-am'. It takes no parameter,

66 +This hook is invoked by 'git am'. It takes no parameter,

67 and is invoked after the patch is applied and a commit is made.

69 This hook is meant primarily for notification, and cannot affect

70 -the outcome of 'git-am'.

70 +the outcome of 'git am'.

72 pre-commit

73 ~~~~~~~~~~

75 -This hook is invoked by 'git-commit', and can be bypassed

75 +This hook is invoked by 'git commit', and can be bypassed

76 with `\--no-verify` option. It takes no parameter, and is

77 invoked before obtaining the proposed commit log message and

78 making a commit. Exiting with non-zero status from this script

79 -causes the 'git-commit' to abort.

79 +causes the 'git commit' to abort.

81 The default 'pre-commit' hook, when enabled, catches introduction

82 of lines with trailing whitespaces and aborts the commit when

83 such a line is found.

85 -All the 'git-commit' hooks are invoked with the environment

85 +All the 'git commit' hooks are invoked with the environment

86 variable `GIT_EDITOR=:` if the command will not bring up an editor

87 to modify the commit message.

89 prepare-commit-msg

90 ~~~~~~~~~~~~~~~~~~

92 -This hook is invoked by 'git-commit' right after preparing the

92 +This hook is invoked by 'git commit' right after preparing the

93 default log message, and before the editor is started.

95 It takes one to three parameters. The first is the name of the file

@@ -101,7 +101,7 @@ commit is a merge or a `.git/MERGE_MSG` file exists); `squash`

101 (if a `.git/SQUASH_MSG` file exists); or `commit`, followed by

102 a commit SHA1 (if a `-c`, `-C` or `\--amend` option was given).

103

104 -If the exit status is non-zero, 'git-commit' will abort.

104 +If the exit status is non-zero, 'git commit' will abort.

105

106 The purpose of the hook is to edit the message file in place, and

107 it is not suppressed by the `\--no-verify` option. A non-zero exit

@@ -114,10 +114,10 @@ out the `Conflicts:` part of a merge's commit message.

114 commit-msg

115 ~~~~~~~~~~

116

117 -This hook is invoked by 'git-commit', and can be bypassed

117 +This hook is invoked by 'git commit', and can be bypassed

118 with `\--no-verify` option. It takes a single parameter, the

119 name of the file that holds the proposed commit log message.

120 -Exiting with non-zero status causes the 'git-commit' to

120 +Exiting with non-zero status causes the 'git commit' to

121 abort.

122

123 The hook is allowed to edit the message file in place, and can

@@ -131,30 +131,30 @@ The default 'commit-msg' hook, when enabled, detects duplicate

131 post-commit

132 ~~~~~~~~~~~

133

134 -This hook is invoked by 'git-commit'. It takes no

134 +This hook is invoked by 'git commit'. It takes no

135 parameter, and is invoked after a commit is made.

136

137 This hook is meant primarily for notification, and cannot affect

138 -the outcome of 'git-commit'.

138 +the outcome of 'git commit'.

139

140 pre-rebase

141 ~~~~~~~~~~

142

143 -This hook is called by 'git-rebase' and can be used to prevent a branch

143 +This hook is called by 'git rebase' and can be used to prevent a branch

144 from getting rebased.

145

146

147 post-checkout

148 ~~~~~~~~~~~~~

149

150 -This hook is invoked when a 'git-checkout' is run after having updated the

150 +This hook is invoked when a 'git checkout' is run after having updated the

151 worktree. The hook is given three parameters: the ref of the previous HEAD,

152 the ref of the new HEAD (which may or may not have changed), and a flag

153 indicating whether the checkout was a branch checkout (changing branches,

154 flag=1) or a file checkout (retrieving a file from the index, flag=0).

155 -This hook cannot affect the outcome of 'git-checkout'.

155 +This hook cannot affect the outcome of 'git checkout'.

156

157 -It is also run after 'git-clone', unless the --no-checkout (-n) option is

157 +It is also run after 'git clone', unless the --no-checkout (-n) option is

158 used. The first parameter given to the hook is the null-ref, the second the

159 ref of the new HEAD and the flag is always 1.

160

@@ -165,10 +165,10 @@ properties.

165 post-merge

166 ~~~~~~~~~~

167

168 -This hook is invoked by 'git-merge', which happens when a 'git-pull'

168 +This hook is invoked by 'git merge', which happens when a 'git pull'

169 is done on a local repository. The hook takes a single parameter, a status

170 flag specifying whether or not the merge being done was a squash merge.

171 -This hook cannot affect the outcome of 'git-merge' and is not executed,

171 +This hook cannot affect the outcome of 'git merge' and is not executed,

172 if the merge failed due to conflicts.

173

174 This hook can be used in conjunction with a corresponding pre-commit hook to

@@ -181,7 +181,7 @@ pre-receive

181 ~~~~~~~~~~~

182

183 This hook is invoked by 'git-receive-pack' on the remote repository,

184 -which happens when a 'git-push' is done on a local repository.

184 +which happens when a 'git push' is done on a local repository.

185 Just before starting to update refs on the remote repository, the

186 pre-receive hook is invoked. Its exit status determines the success

187 or failure of the update.

@@ -202,7 +202,7 @@ updated. If the hook exits with zero, updating of individual refs can

202 still be prevented by the <<update,'update'>> hook.

203

204 Both standard output and standard error output are forwarded to

205 -'git-send-pack' on the other end, so you can simply `echo` messages

205 +'git send-pack' on the other end, so you can simply `echo` messages

206 for the user.

207

208 [[update]]

@@ -210,7 +210,7 @@ update

210 ~~~~~~

211

212 This hook is invoked by 'git-receive-pack' on the remote repository,

213 -which happens when a 'git-push' is done on a local repository.

213 +which happens when a 'git push' is done on a local repository.

214 Just before updating the ref on the remote repository, the update hook

215 is invoked. Its exit status determines the success or failure of

216 the ref update.

@@ -241,7 +241,7 @@ implement access control which is finer grained than the one

241 based on filesystem group.

242

243 Both standard output and standard error output are forwarded to

244 -'git-send-pack' on the other end, so you can simply `echo` messages

244 +'git send-pack' on the other end, so you can simply `echo` messages

245 for the user.

246

247 The default 'update' hook, when enabled--and with

@@ -253,7 +253,7 @@ post-receive

253 ~~~~~~~~~~~~

254

255 This hook is invoked by 'git-receive-pack' on the remote repository,

256 -which happens when a 'git-push' is done on a local repository.

256 +which happens when a 'git push' is done on a local repository.

257 It executes on the remote repository once after all the refs have

258 been updated.

259

@@ -270,7 +270,7 @@ both old and new values of all the refs in addition to their

270 names.

271

272 Both standard output and standard error output are forwarded to

273 -'git-send-pack' on the other end, so you can simply `echo` messages

273 +'git send-pack' on the other end, so you can simply `echo` messages

274 for the user.

275

276 The default 'post-receive' hook is empty, but there is

@@ -283,7 +283,7 @@ post-update

283 ~~~~~~~~~~~

284

285 This hook is invoked by 'git-receive-pack' on the remote repository,

286 -which happens when a 'git-push' is done on a local repository.

286 +which happens when a 'git push' is done on a local repository.

287 It executes on the remote repository once after all the refs have

288 been updated.

289

@@ -301,20 +301,20 @@ updated values of the refs. You might consider it instead if you need

301 them.

302

303 When enabled, the default 'post-update' hook runs

304 -'git-update-server-info' to keep the information used by dumb

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

307 probably enable this hook.

308

309 Both standard output and standard error output are forwarded to

310 -'git-send-pack' on the other end, so you can simply `echo` messages

310 +'git send-pack' on the other end, so you can simply `echo` messages

311 for the user.

312

313 pre-auto-gc

314 ~~~~~~~~~~~

315

316 -This hook is invoked by 'git-gc --auto'. It takes no parameter, and

317 -exiting with non-zero status from this script causes the 'git-gc --auto'

316 +This hook is invoked by 'git gc --auto'. It takes no parameter, and

317 +exiting with non-zero status from this script causes the 'git gc --auto'

318 to abort.

319

320 GIT

Documentation/gitignore.txt

+2 -2

@@ -56,10 +56,10 @@ the user's editor of choice) generally go into a file specified by

56 `core.excludesfile` in the user's `~/.gitconfig`.

58 The underlying git plumbing tools, such as

59 -'git-ls-files' and 'git-read-tree', read

59 +'git ls-files' and 'git read-tree', read

60 `gitignore` patterns specified by command-line options, or from

61 files specified by command-line options. Higher-level git

62 -tools, such as 'git-status' and 'git-add',

62 +tools, such as 'git status' and 'git add',

63 use patterns from the sources specified above.

65 Patterns have the following format:

Documentation/gitk.txt

+1 -1

@@ -22,7 +22,7 @@ git repository.

22 OPTIONS

23 -------

24 To control which revisions to show, the command takes options applicable to

25 -the 'git-rev-list' command (see linkgit:git-rev-list[1]).

25 +the 'git rev-list' command (see linkgit:git-rev-list[1]).

26 This manual page describes only the most

27 frequently used options.

Documentation/gitrepository-layout.txt

+9 -9

@@ -64,7 +64,7 @@ objects/info/packs::

64 are available in this object store. Whenever a pack is

65 added or removed, `git update-server-info` should be run

66 to keep this file up-to-date if the repository is

67 - published for dumb transports. 'git-repack' does this

67 + published for dumb transports. 'git repack' does this

68 by default.

70 objects/info/alternates::

@@ -85,7 +85,7 @@ objects/info/http-alternates::

86 refs::

87 References are stored in subdirectories of this

88 - directory. The 'git-prune' command knows to keep

88 + directory. The 'git prune' command knows to keep

89 objects reachable from refs found in this directory and

90 its subdirectories.

@@ -125,7 +125,7 @@ details.

125

126 branches::

127 A slightly deprecated way to store shorthands to be used

128 - to specify URL to 'git-fetch', 'git-pull' and 'git-push'

128 + to specify URL to 'git fetch', 'git pull' and 'git push'

129 commands is to store a file in `branches/<name>` and

130 give 'name' to these commands in place of 'repository'

131 argument.

@@ -133,7 +133,7 @@ branches::

133 hooks::

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

136 + 'git init' is run, but all of them are disabled by

137 default. To enable, the `.sample` suffix has to be

138 removed from the filename by renaming.

139 Read linkgit:githooks[5] for more details about

@@ -151,10 +151,10 @@ info/refs::

151 This file helps dumb transports discover what refs are

152 available in this repository. If the repository is

153 published for dumb transports, this file should be

154 - regenerated by 'git-update-server-info' every time a tag

154 + regenerated by 'git update-server-info' every time a tag

155 or branch is created or modified. This is normally done

156 from the `hooks/update` hook, which is run by the

157 - 'git-receive-pack' command when you 'git-push' into the

157 + 'git-receive-pack' command when you 'git push' into the

158 repository.

159

160 info/grafts::

@@ -168,14 +168,14 @@ info/grafts::

168 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

171 + ignore file. 'git status', 'git add', 'git rm' and

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::

176 Stores shorthands to be used to give URL and default

177 refnames to interact with remote repository to

178 - 'git-fetch', 'git-pull' and 'git-push' commands.

178 + 'git fetch', 'git pull' and 'git push' commands.

179

180 logs::

181 Records of changes made to refs are stored in this

Documentation/gittutorial-2.txt

+8 -8

@@ -260,7 +260,7 @@ index a042389..513feba 100644

260 +hello world, again

261 ------------------------------------------------

262

263 -So 'git-diff' is comparing against something other than the head.

263 +So 'git diff' is comparing against something other than the head.

264 The thing that it's comparing against is actually the index file,

265 which is stored in .git/index in a binary format, but whose contents

266 we can examine with ls-files:

@@ -275,9 +275,9 @@ hello world!

275 hello world, again

276 ------------------------------------------------

277

278 -So what our 'git-add' did was store a new blob and then put

278 +So what our 'git add' did was store a new blob and then put

279 a reference to it in the index file. If we modify the file again,

280 -we'll see that the new modifications are reflected in the 'git-diff'

280 +we'll see that the new modifications are reflected in the 'git diff'

281 output:

282

283 ------------------------------------------------

@@ -292,7 +292,7 @@ index 513feba..ba3da7b 100644

292 +again?

293 ------------------------------------------------

294

295 -With the right arguments, 'git-diff' can also show us the difference

295 +With the right arguments, 'git diff' can also show us the difference

296 between the working directory and the last commit, or between the

297 index and the last commit:

298

@@ -316,7 +316,7 @@ index a042389..513feba 100644

316 +hello world, again

317 ------------------------------------------------

318

319 -At any time, we can create a new commit using 'git-commit' (without

319 +At any time, we can create a new commit using 'git commit' (without

320 the "-a" option), and verify that the state committed only includes the

321 changes stored in the index file, not the additional change that is

322 still only in our working tree:

@@ -334,11 +334,11 @@ index 513feba..ba3da7b 100644

334 +again?

335 ------------------------------------------------

336

337 -So by default 'git-commit' uses the index to create the commit, not

337 +So by default 'git commit' uses the index to create the commit, not

338 the working tree; the "-a" option to commit tells it to first update

339 the index with all changes in the working tree.

340

341 -Finally, it's worth looking at the effect of 'git-add' on the index

341 +Finally, it's worth looking at the effect of 'git add' on the index

342 file:

343

344 ------------------------------------------------

@@ -346,7 +346,7 @@ $ echo "goodbye, world" >closing.txt

346 $ git add closing.txt

347 ------------------------------------------------

348

349 -The effect of the 'git-add' was to add one entry to the index file:

349 +The effect of the 'git add' was to add one entry to the index file:

350

351 ------------------------------------------------

352 $ git ls-files --stage

Documentation/gittutorial.txt

+21 -21

@@ -67,7 +67,7 @@ You've now initialized the working directory--you may notice a new

67 directory created, named ".git".

69 Next, tell git to take a snapshot of the contents of all files under the

70 -current directory (note the '.'), with 'git-add':

70 +current directory (note the '.'), with 'git add':

72 ------------------------------------------------

73 $ git add .

@@ -75,7 +75,7 @@ $ git add .

76 This snapshot is now stored in a temporary staging area which git calls

77 the "index". You can permanently store the contents of the index in the

78 -repository with 'git-commit':

78 +repository with 'git commit':

80 ------------------------------------------------

81 $ git commit

@@ -94,15 +94,15 @@ $ git add file1 file2 file3

94 ------------------------------------------------

96 You are now ready to commit. You can see what is about to be committed

97 -using 'git-diff' with the --cached option:

97 +using 'git diff' with the --cached option:

99 ------------------------------------------------

100 $ git diff --cached

101 ------------------------------------------------

102

103 -(Without --cached, 'git-diff' will show you any changes that

103 +(Without --cached, 'git diff' will show you any changes that

104 you've made but not yet added to the index.) You can also get a brief

105 -summary of the situation with 'git-status':

105 +summary of the situation with 'git status':

106

107 ------------------------------------------------

108 $ git status

@@ -126,7 +126,7 @@ $ git commit

126 This will again prompt you for a message describing the change, and then

127 record a new version of the project.

128

129 -Alternatively, instead of running 'git-add' beforehand, you can use

129 +Alternatively, instead of running 'git add' beforehand, you can use

130

131 ------------------------------------------------

132 $ git commit -a

@@ -147,7 +147,7 @@ Git tracks content not files

147

148 Many revision control systems provide an `add` command that tells the

149 system to start tracking changes to a new file. Git's `add` command

150 -does something simpler and more powerful: 'git-add' is used both for new

150 +does something simpler and more powerful: 'git add' is used both for new

151 and newly modified files, and in both cases it takes a snapshot of the

152 given files and stages that content in the index, ready for inclusion in

153 the next commit.

@@ -376,7 +376,7 @@ alice$ git remote add bob /home/bob/myrepo

376 ------------------------------------------------

377

378 With this, Alice can perform the first part of the "pull" operation

379 -alone using the 'git-fetch' command without merging them with her own

379 +alone using the 'git fetch' command without merging them with her own

380 branch, using:

381

382 -------------------------------------

@@ -384,7 +384,7 @@ alice$ git fetch bob

384 -------------------------------------

385

386 Unlike the longhand form, when Alice fetches from Bob using a

387 -remote repository shorthand set up with 'git-remote', what was

387 +remote repository shorthand set up with 'git remote', what was

388 fetched is stored in a remote tracking branch, in this case

389 `bob/master`. So after this:

390

@@ -428,7 +428,7 @@ bob$ git config --get remote.origin.url

428 /home/alice/project

429 -------------------------------------

430

431 -(The complete configuration created by 'git-clone' is visible using

431 +(The complete configuration created by 'git clone' is visible using

432 `git config -l`, and the linkgit:git-config[1] man page

433 explains the meaning of each option.)

434

@@ -458,7 +458,7 @@ Exploring history

458 -----------------

459

460 Git history is represented as a series of interrelated commits. We

461 -have already seen that the 'git-log' command can list those commits.

461 +have already seen that the 'git log' command can list those commits.

462 Note that first line of each git log entry also gives a name for the

463 commit:

464

@@ -471,7 +471,7 @@ Date: Tue May 16 17:18:22 2006 -0700

471 merge-base: Clarify the comments on post processing.

472 -------------------------------------

473

474 -We can give this name to 'git-show' to see the details about this

474 +We can give this name to 'git show' to see the details about this

475 commit.

476

477 -------------------------------------

@@ -529,13 +529,13 @@ $ git reset --hard HEAD^ # reset your current branch and working

529 Be careful with that last command: in addition to losing any changes

530 in the working directory, it will also remove all later commits from

531 this branch. If this branch is the only branch containing those

532 -commits, they will be lost. Also, don't use 'git-reset' on a

532 +commits, they will be lost. Also, don't use 'git reset' on a

533 publicly-visible branch that other developers pull from, as it will

534 force needless merges on other developers to clean up the history.

535 -If you need to undo changes that you have pushed, use 'git-revert'

535 +If you need to undo changes that you have pushed, use 'git revert'

536 instead.

537

538 -The 'git-grep' command can search for strings in any version of your

538 +The 'git grep' command can search for strings in any version of your

539 project, so

540

541 -------------------------------------

@@ -544,7 +544,7 @@ $ git grep "hello" v2.5

544

545 searches for all occurrences of "hello" in v2.5.

546

547 -If you leave out the commit name, 'git-grep' will search any of the

547 +If you leave out the commit name, 'git grep' will search any of the

548 files it manages in your current directory. So

549

550 -------------------------------------

@@ -554,7 +554,7 @@ $ git grep "hello"

554 is a quick way to search just the files that are tracked by git.

555

556 Many git commands also take sets of commits, which can be specified

557 -in a number of ways. Here are some examples with 'git-log':

557 +in a number of ways. Here are some examples with 'git log':

558

559 -------------------------------------

560 $ git log v2.5..v2.6 # commits between v2.5 and v2.6

@@ -564,7 +564,7 @@ $ git log v2.5.. Makefile # commits since v2.5 which modify

564 # Makefile

565 -------------------------------------

566

567 -You can also give 'git-log' a "range" of commits where the first is not

567 +You can also give 'git log' a "range" of commits where the first is not

568 necessarily an ancestor of the second; for example, if the tips of

569 the branches "stable" and "master" diverged from a common

570 commit some time ago, then

@@ -583,9 +583,9 @@ $ git log master..stable

583 will show the list of commits made on the stable branch but not

584 the master branch.

585

586 -The 'git-log' command has a weakness: it must present commits in a

586 +The 'git log' command has a weakness: it must present commits in a

587 list. When the history has lines of development that diverged and

588 -then merged back together, the order in which 'git-log' presents

588 +then merged back together, the order in which 'git log' presents

589 those commits is meaningless.

590

591 Most projects with multiple contributors (such as the Linux kernel,

@@ -609,7 +609,7 @@ of the file:

609 $ git diff v2.5:Makefile HEAD:Makefile.in

610 -------------------------------------

611

612 -You can also use 'git-show' to see any such file:

612 +You can also use 'git show' to see any such file:

613

614 -------------------------------------

615 $ git show v2.5:Makefile

Documentation/gitworkflows.txt

+3 -3

@@ -360,7 +360,7 @@ There are three main tools that can be used for this:

360

361 * linkgit:git-pull[1] that does fetch and merge in one go.

362

363 -Note the last point. Do 'not' use 'git-pull' unless you actually want

363 +Note the last point. Do 'not' use 'git pull' unless you actually want

364 to merge the remote branch.

365

366 Getting changes out is easy:

@@ -397,7 +397,7 @@ Please pull from

397 <url> <branch>

398 -------------------------------------

399

400 -In that case, 'git-pull' can do the fetch and merge in one go, as

400 +In that case, 'git pull' can do the fetch and merge in one go, as

401 follows.

402

403 .Push/pull: Merging remote topics

@@ -449,7 +449,7 @@ problem.

449

450 If you receive such a patch series (as maintainer, or perhaps as a

451 reader of the mailing list it was sent to), save the mails to files,

452 -create a new topic branch and use 'git-am' to import the commits:

452 +create a new topic branch and use 'git am' to import the commits:

453

454 .format-patch/am: Importing patches

455 [caption="Recipe: "]

Documentation/i18n.txt

+2 -2

@@ -21,7 +21,7 @@ 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.

24 -. 'git-commit' and 'git-commit-tree' issues

24 +. 'git commit' and 'git commit-tree' issues

25 a warning if the commit log message given to it does not look

26 like a valid UTF-8 string, unless you explicitly say your

27 project uses a legacy encoding. The way to say this is to

@@ -37,7 +37,7 @@ of `i18n.commitencoding` in its `encoding` header. This is to

37 help other people who look at them later. Lack of this header

38 implies that the commit log message is encoded in UTF-8.

40 -. 'git-log', 'git-show', 'git-blame' and friends look at the

40 +. 'git log', 'git show', 'git blame' and friends look at the

41 `encoding` header of a commit object, and try to re-code the

42 log message into UTF-8 unless otherwise specified. You can

43 specify the desired output encoding with

Documentation/merge-options.txt

+2 -2

@@ -59,8 +59,8 @@ option can be used to override --squash.

59 Use the given merge strategy; can be supplied more than

60 once to specify them in the order they should be tried.

61 If there is no `-s` option, a built-in list of strategies

62 - is used instead ('git-merge-recursive' when merging a single

63 - head, 'git-merge-octopus' otherwise).

62 + is used instead ('git merge-recursive' when merging a single

63 + head, 'git merge-octopus' otherwise).

65 --summary::

66 --no-summary::

Documentation/pull-fetch-param.txt

+4 -4

@@ -38,7 +38,7 @@ must know this is the expected usage pattern for a branch.

38 [NOTE]

39 You never do your own development on branches that appear

40 on the right hand side of a <refspec> colon on `Pull:` lines;

41 -they are to be updated by 'git-fetch'. If you intend to do

41 +they are to be updated by 'git fetch'. If you intend to do

42 development derived from a remote branch `B`, have a `Pull:`

43 line to track it (i.e. `Pull: B:remote-B`), and have a separate

44 branch `my-B` to do your development on top of it. The latter

@@ -50,13 +50,13 @@ on the remote branch, merge it into your development branch with

50 +

51 [NOTE]

52 There is a difference between listing multiple <refspec>

53 -directly on 'git-pull' command line and having multiple

53 +directly on 'git pull' command line and having multiple

54 `Pull:` <refspec> lines for a <repository> and running

55 -'git-pull' command without any explicit <refspec> parameters.

55 +'git pull' command without any explicit <refspec> parameters.

56 <refspec> listed explicitly on the command line are always

57 merged into the current branch after fetching. In other words,

58 if you list more than one remote refs, you would be making

59 -an Octopus. While 'git-pull' run without any explicit <refspec>

59 +an Octopus. While 'git pull' run without any explicit <refspec>

60 parameter takes default <refspec>s from `Pull:` lines, it

61 merges only the first <refspec> found into the current branch,

62 after fetching all the remote refs. This is because making an

Documentation/urls-remotes.txt

+2 -2

@@ -52,8 +52,8 @@ following format:

53 ------------

55 -`Push:` lines are used by 'git-push' and

56 -`Pull:` lines are used by 'git-pull' and 'git-fetch'.

55 +`Push:` lines are used by 'git push' and

56 +`Pull:` lines are used by 'git pull' and 'git fetch'.

57 Multiple `Push:` and `Pull:` lines may

58 be specified for additional branch mappings.