@matheusbsbs / matheus-bagliano / commits / b1889c36d8
Fork 0

Documentation: be consistent about "git-" versus "git "

Since the git-* commands are not installed in $(bindir), using "git-command <parameters>" in examples in the documentation is not a good idea. On the other hand, it is nice to be able to refer to each command using one hyphenated word. (There is no escaping it, anyway: man page names cannot have spaces in them.) This patch retains the dash in naming an operation, command, program, process, or action. Complete command lines that can be entered at a shell (i.e., without options omitted) are made to use the dashless form. The changes consist only of replacing some spaces with hyphens and vice versa. After a "s/ /-/g", the unpatched and patched versions are identical. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Jonathan Nieder committed Jun 30, 2008 at 01:09 UTC b1889c36d85514e5e70462294c561a02c2edfe2b
131 files changed +462 -462
Documentation/git-add.txt
+1 -1
@@ -8,7 +8,7 @@ git-add - Add file contents to the index
8 SYNOPSIS
9 --------
10 [verse]
11 -'git-add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
11 +'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
12 [--update | -u] [--refresh] [--ignore-errors] [--]
13 <filepattern>...
14
Documentation/git-am.txt
+2 -2
@@ -9,11 +9,11 @@ git-am - Apply a series of patches from a mailbox
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-am' [--signoff] [--keep] [--utf8 | --no-utf8]
12 +'git am' [--signoff] [--keep] [--utf8 | --no-utf8]
13 [--3way] [--interactive] [--binary]
14 [--whitespace=<option>] [-C<n>] [-p<n>]
15 <mbox>|<Maildir>...
16 -'git-am' [--skip | --resolved]
16 +'git am' [--skip | --resolved]
17
18 DESCRIPTION
19 -----------
Documentation/git-annotate.txt
+1 -1
@@ -7,7 +7,7 @@ git-annotate - Annotate file lines with commit info
7
8 SYNOPSIS
9 --------
10 -git-annotate [options] file [revision]
10 +git annotate [options] file [revision]
11
12 DESCRIPTION
13 -----------
Documentation/git-apply.txt
+1 -1
@@ -9,7 +9,7 @@ git-apply - Apply a patch on a git index file and a working tree
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-apply' [--stat] [--numstat] [--summary] [--check] [--index]
12 +'git apply' [--stat] [--numstat] [--summary] [--check] [--index]
13 [--apply] [--no-add] [--build-fake-ancestor <file>] [-R | --reverse]
14 [--allow-binary-replacement | --binary] [--reject] [-z]
15 [-pNUM] [-CNUM] [--inaccurate-eof] [--recount] [--cached]
Documentation/git-archimport.txt
+1 -1
@@ -9,7 +9,7 @@ git-archimport - Import an Arch repository into git
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
12 +'git archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
13 <archive/branch>[:<git-branch>] ...
14
15 DESCRIPTION
Documentation/git-archive.txt
+1 -1
@@ -9,7 +9,7 @@ git-archive - Create an archive of files from a named tree
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
12 +'git archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
13 [--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
14 [path...]
15
Documentation/git-bisect.txt
+1 -1
@@ -26,7 +26,7 @@ on the subcommand:
26 git bisect log
27 git bisect run <cmd>...
28
29 -This command uses 'git-rev-list --bisect' option to help drive the
29 +This command uses 'git rev-list --bisect' option to help drive the
30 binary search process to find which change introduced a bug, given an
31 old "good" commit object name and a later "bad" commit object name.
32
Documentation/git-blame.txt
+1 -1
@@ -8,7 +8,7 @@ git-blame - Show what revision and author last modified each line of a file
8 SYNOPSIS
9 --------
10 [verse]
11 -'git-blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
11 +'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
12 [-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
13 [<rev> | --contents <file>] [--] <file>
14
Documentation/git-branch.txt
+4 -4
@@ -8,12 +8,12 @@ git-branch - List, create, or delete branches
8 SYNOPSIS
9 --------
10 [verse]
11 -'git-branch' [--color | --no-color] [-r | -a] [--merged | --no-merged]
11 +'git branch' [--color | --no-color] [-r | -a] [--merged | --no-merged]
12 [-v [--abbrev=<length> | --no-abbrev]]
13 [--contains <commit>]
14 -'git-branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
15 -'git-branch' (-m | -M) [<oldbranch>] <newbranch>
16 -'git-branch' (-d | -D) [-r] <branchname>...
14 +'git branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
15 +'git branch' (-m | -M) [<oldbranch>] <newbranch>
16 +'git branch' (-d | -D) [-r] <branchname>...
17
18 DESCRIPTION
19 -----------
Documentation/git-bundle.txt
+7 -7
@@ -9,10 +9,10 @@ git-bundle - Move objects and refs by archive
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-bundle' create <file> <git-rev-list args>
13 -'git-bundle' verify <file>
14 -'git-bundle' list-heads <file> [refname...]
15 -'git-bundle' unbundle <file> [refname...]
12 +'git bundle' create <file> <git-rev-list args>
13 +'git bundle' verify <file>
14 +'git bundle' list-heads <file> [refname...]
15 +'git bundle' unbundle <file> [refname...]
16
17 DESCRIPTION
18 -----------
@@ -116,7 +116,7 @@ We set a tag in R1 (lastR2bundle) after the previous such transport,
116 and move it afterwards to help build the bundle.
117
118 ------------
119 -$ git-bundle create mybundle master ^lastR2bundle
119 +$ git bundle create mybundle master ^lastR2bundle
120 $ git tag -f lastR2bundle master
121 ------------
122
@@ -141,8 +141,8 @@ $ git bundle create mybundle master -n 10
141 Then you move mybundle from A to B, and in R2 on B:
142
143 ------------
144 -$ git-bundle verify mybundle
145 -$ git-fetch mybundle master:localRef
144 +$ git bundle verify mybundle
145 +$ git fetch mybundle master:localRef
146 ------------
147
148 With something like this in the config in R2:
Documentation/git-cat-file.txt
+2 -2
@@ -9,8 +9,8 @@ git-cat-file - Provide content or type/size information for repository objects
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-cat-file' [-t | -s | -e | -p | <type>] <object>
13 -'git-cat-file' [--batch | --batch-check] < <list-of-objects>
12 +'git cat-file' [-t | -s | -e | -p | <type>] <object>
13 +'git cat-file' [--batch | --batch-check] < <list-of-objects>
14
15 DESCRIPTION
16 -----------
Documentation/git-check-attr.txt
+1 -1
@@ -8,7 +8,7 @@ git-check-attr - Display gitattributes information.
8
9 SYNOPSIS
10 --------
11 -'git-check-attr' attr... [--] pathname...
11 +'git check-attr' attr... [--] pathname...
12
13 DESCRIPTION
14 -----------
Documentation/git-check-ref-format.txt
+2 -2
@@ -7,7 +7,7 @@ git-check-ref-format - Make sure ref name is well formed
7
8 SYNOPSIS
9 --------
10 -'git-check-ref-format' <refname>
10 +'git check-ref-format' <refname>
11
12 DESCRIPTION
13 -----------
@@ -47,7 +47,7 @@ refname expressions (see linkgit:git-rev-parse[1]). Namely:
47 . colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
48 value and store it in dstref" in fetch and push operations.
49 It may also be used to select a specific object such as with
50 - linkgit:git-cat-file[1] "git-cat-file blob v1.3.3:refs.c".
50 + linkgit:git-cat-file[1] "git cat-file blob v1.3.3:refs.c".
51
52
53 GIT
Documentation/git-checkout-index.txt
+10 -10
@@ -9,7 +9,7 @@ git-checkout-index - Copy files from the index to the working tree
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
12 +'git checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
13 [--stage=<number>|all]
14 [--temp]
15 [-z] [--stdin]
@@ -73,16 +73,16 @@ OPTIONS
73
74 The order of the flags used to matter, but not anymore.
75
76 -Just doing `git-checkout-index` does nothing. You probably meant
77 -`git-checkout-index -a`. And if you want to force it, you want
78 -`git-checkout-index -f -a`.
76 +Just doing `git checkout-index` does nothing. You probably meant
77 +`git checkout-index -a`. And if you want to force it, you want
78 +`git checkout-index -f -a`.
79
80 Intuitiveness is not the goal here. Repeatability is. The reason for
81 the "no arguments means no work" behavior is that from scripts you are
82 supposed to be able to do:
83
84 ----------------
85 -$ find . -name '*.h' -print0 | xargs -0 git-checkout-index -f --
85 +$ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
86 ----------------
87
88 which will force all existing `*.h` files to be replaced with their
@@ -91,7 +91,7 @@ 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:
92
93 ----------------
94 -$ find . -name '*.h' -print0 | git-checkout-index -f -z --stdin
94 +$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
95 ----------------
96
97 The `--` is just a good idea when you know the rest will be filenames;
@@ -144,7 +144,7 @@ EXAMPLES
144 To update and refresh only the files already checked out::
145 +
146 ----------------
147 -$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
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"::
@@ -153,10 +153,10 @@ Using `git-checkout-index` to "export an entire tree"::
153 Just read the desired tree into the index, and do:
154 +
155 ----------------
156 -$ git-checkout-index --prefix=git-export-dir/ -a
156 +$ git checkout-index --prefix=git-export-dir/ -a
157 ----------------
158 +
159 -`git-checkout-index` will "export" the index into the specified
159 +`git checkout-index` will "export" the index into the specified
160 directory.
161 +
162 The final "/" is important. The exported name is literally just
@@ -166,7 +166,7 @@ following example.
166 Export files with a prefix::
167 +
168 ----------------
169 -$ git-checkout-index --prefix=.merged- Makefile
169 +$ git checkout-index --prefix=.merged- Makefile
170 ----------------
171 +
172 This will check out the currently cached copy of `Makefile`
Documentation/git-checkout.txt
+4 -4
@@ -8,8 +8,8 @@ git-checkout - Checkout a branch or paths to the working tree
8 SYNOPSIS
9 --------
10 [verse]
11 -'git-checkout' [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>]
12 -'git-checkout' [<tree-ish>] <paths>...
11 +'git checkout' [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>]
12 +'git checkout' [<tree-ish>] <paths>...
13
14 DESCRIPTION
15 -----------
@@ -23,7 +23,7 @@ options, which will be passed to `git branch`.
23
24 When <paths> are given, this command does *not* switch
25 branches. It updates the named paths in the working tree from
26 -the index file (i.e. it runs `git-checkout-index -f -u`), or
26 +the index file (i.e. it runs `git checkout-index -f -u`), or
27 from a named commit. In
28 this case, the `-f` and `-b` options are meaningless and giving
29 either of them results in an error. <tree-ish> argument can be
@@ -112,7 +112,7 @@ current branch and directly point at the commit named by the tag
112 (`v2.6.18` in the above example).
113
114 You can use usual git commands while in this state. You can use
115 -`git-reset --hard $othercommit` to further move around, for
115 +`git reset --hard $othercommit` to further move around, for
116 example. You can make changes and create a new commit on top of
117 a detached HEAD. You can even create a merge by using `git
118 merge $othercommit`.
Documentation/git-cherry-pick.txt
+1 -1
@@ -7,7 +7,7 @@ git-cherry-pick - Apply the change introduced by an existing commit
7
8 SYNOPSIS
9 --------
10 -'git-cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] <commit>
10 +'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] <commit>
11
12 DESCRIPTION
13 -----------
Documentation/git-cherry.txt
+1 -1
@@ -7,7 +7,7 @@ git-cherry - Find commits not merged upstream
7
8 SYNOPSIS
9 --------
10 -'git-cherry' [-v] <upstream> [<head>] [<limit>]
10 +'git cherry' [-v] <upstream> [<head>] [<limit>]
11
12 DESCRIPTION
13 -----------
Documentation/git-clean.txt
+1 -1
@@ -8,7 +8,7 @@ git-clean - Remove untracked files from the working tree
8 SYNOPSIS
9 --------
10 [verse]
11 -'git-clean' [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...
11 +'git clean' [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...
12
13 DESCRIPTION
14 -----------
Documentation/git-clone.txt
+1 -1
@@ -9,7 +9,7 @@ git-clone - Clone a repository into a new directory
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-clone' [--template=<template_directory>]
12 +'git clone' [--template=<template_directory>]
13 [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare]
14 [-o <name>] [-u <upload-pack>] [--reference <repository>]
15 [--depth <depth>] [--] <repository> [<directory>]
Documentation/git-commit-tree.txt
+1 -1
@@ -8,7 +8,7 @@ git-commit-tree - Create a new commit object
8
9 SYNOPSIS
10 --------
11 -'git-commit-tree' <tree> [-p <parent commit>]\* < changelog
11 +'git commit-tree' <tree> [-p <parent commit>]\* < changelog
12
13 DESCRIPTION
14 -----------
Documentation/git-commit.txt
+2 -2
@@ -8,7 +8,7 @@ git-commit - Record changes to the repository
8 SYNOPSIS
9 --------
10 [verse]
11 -'git-commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend]
11 +'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend]
12 [(-c | -C) <commit>] [-F <file> | -m <msg>]
13 [--allow-empty] [--no-verify] [-e] [--author=<author>]
14 [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
@@ -207,7 +207,7 @@ When recording your own work, the contents of modified files in
207 your working tree are temporarily stored to a staging area
208 called the "index" with linkgit:git-add[1]. A file can be
209 reverted back, only in the index but not in the working tree,
210 -to that of the last commit with `git-reset HEAD -- <file>`,
210 +to that of the last commit with `git reset HEAD -- <file>`,
211 which effectively reverts `git-add` and prevents the changes to
212 this file from participating in the next commit. After building
213 the state to be committed incrementally with these commands,
Documentation/git-config.txt
+13 -13
@@ -9,19 +9,19 @@ git-config - Get and set repository or global options
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-config' [<file-option>] [type] [-z|--null] name [value [value_regex]]
13 -'git-config' [<file-option>] [type] --add name value
14 -'git-config' [<file-option>] [type] --replace-all name [value [value_regex]]
15 -'git-config' [<file-option>] [type] [-z|--null] --get name [value_regex]
16 -'git-config' [<file-option>] [type] [-z|--null] --get-all name [value_regex]
17 -'git-config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex]
18 -'git-config' [<file-option>] --unset name [value_regex]
19 -'git-config' [<file-option>] --unset-all name [value_regex]
20 -'git-config' [<file-option>] --rename-section old_name new_name
21 -'git-config' [<file-option>] --remove-section name
22 -'git-config' [<file-option>] [-z|--null] -l | --list
23 -'git-config' [<file-option>] --get-color name [default]
24 -'git-config' [<file-option>] --get-colorbool name [stdout-is-tty]
12 +'git config' [<file-option>] [type] [-z|--null] name [value [value_regex]]
13 +'git config' [<file-option>] [type] --add name value
14 +'git config' [<file-option>] [type] --replace-all name [value [value_regex]]
15 +'git config' [<file-option>] [type] [-z|--null] --get name [value_regex]
16 +'git config' [<file-option>] [type] [-z|--null] --get-all name [value_regex]
17 +'git config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex]
18 +'git config' [<file-option>] --unset name [value_regex]
19 +'git config' [<file-option>] --unset-all name [value_regex]
20 +'git config' [<file-option>] --rename-section old_name new_name
21 +'git config' [<file-option>] --remove-section name
22 +'git config' [<file-option>] [-z|--null] -l | --list
23 +'git config' [<file-option>] --get-color name [default]
24 +'git config' [<file-option>] --get-colorbool name [stdout-is-tty]
25
26 DESCRIPTION
27 -----------
Documentation/git-count-objects.txt
+2 -2
@@ -7,7 +7,7 @@ git-count-objects - Count unpacked number of objects and their disk consumption
7
8 SYNOPSIS
9 --------
10 -'git-count-objects' [-v]
10 +'git count-objects' [-v]
11
12 DESCRIPTION
13 -----------
@@ -22,7 +22,7 @@ OPTIONS
22 In addition to the number of loose objects and disk
23 space consumed, it reports the number of in-pack
24 objects, number of packs, and number of objects that can be
25 - removed by running `git-prune-packed`.
25 + removed by running `git prune-packed`.
26
27
28 Author
Documentation/git-cvsexportcommit.txt
+4 -4
@@ -8,7 +8,7 @@ git-cvsexportcommit - Export a single commit to a CVS checkout
8
9 SYNOPSIS
10 --------
11 -'git-cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
11 +'git cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
12
13
14 DESCRIPTION
@@ -89,14 +89,14 @@ Merge one patch into CVS::
89 ------------
90 $ export GIT_DIR=~/project/.git
91 $ cd ~/project_cvs_checkout
92 -$ git-cvsexportcommit -v <commit-sha1>
92 +$ git cvsexportcommit -v <commit-sha1>
93 $ cvs commit -F .msg <files>
94 ------------
95
96 Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo::
97 +
98 ------------
99 - $ git-cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
99 + $ git cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
100 ------------
101
102 Merge pending patches into CVS automatically -- only if you really know what you are doing::
@@ -104,7 +104,7 @@ Merge pending patches into CVS automatically -- only if you really know what you
104 ------------
105 $ export GIT_DIR=~/project/.git
106 $ cd ~/project_cvs_checkout
107 -$ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit -c -p -v
107 +$ git cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git cvsexportcommit -c -p -v
108 ------------
109
110 Author
Documentation/git-cvsimport.txt
+2 -2
@@ -9,7 +9,7 @@ git-cvsimport - Salvage your data out of another SCM people love to hate
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
12 +'git cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
13 [-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
14 [-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
15 [-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>]
@@ -27,7 +27,7 @@ At least version 2.1 is required.
27 You should *never* do any work of your own on the branches that are
28 created by git-cvsimport. By default initial import will create and populate a
29 "master" branch from the CVS repository's main branch which you're free
30 -to work with; after that, you need to 'git merge' incremental imports, or
30 +to work with; after that, you need to 'git-merge' incremental imports, or
31 any CVS branches, yourself. It is advisable to specify a named remote via
32 -r to separate and protect the incoming branches.
33
Documentation/git-cvsserver.txt
+1 -1
@@ -22,7 +22,7 @@ cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
22 Usage:
23
24 [verse]
25 -'git-cvsserver' [options] [pserver|server] [<directory> ...]
25 +'git cvsserver' [options] [pserver|server] [<directory> ...]
26
27 OPTIONS
28 -------
Documentation/git-daemon.txt
+1 -1
@@ -8,7 +8,7 @@ git-daemon - A really simple server for git repositories
8 SYNOPSIS
9 --------
10 [verse]
11 -'git-daemon' [--verbose] [--syslog] [--export-all]
11 +'git daemon' [--verbose] [--syslog] [--export-all]
12 [--timeout=n] [--init-timeout=n] [--strict-paths]
13 [--base-path=path] [--user-path | --user-path=path]
14 [--interpolated-path=pathtemplate]
Documentation/git-describe.txt
+5 -5
@@ -8,7 +8,7 @@ git-describe - Show the most recent tag that is reachable from a commit
8
9 SYNOPSIS
10 --------
11 -'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
11 +'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
12
13 DESCRIPTION
14 -----------
@@ -78,7 +78,7 @@ EXAMPLES
78
79 With something like git.git current tree, I get:
80
81 - [torvalds@g5 git]$ git-describe parent
81 + [torvalds@g5 git]$ git describe parent
82 v1.0.4-14-g2414721
83
84 i.e. the current head of my "parent" branch is based on v1.0.4,
@@ -94,7 +94,7 @@ of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
94
95 Doing a "git-describe" on a tag-name will just show the tag name:
96
97 - [torvalds@g5 git]$ git-describe v1.0.4
97 + [torvalds@g5 git]$ git describe v1.0.4
98 v1.0.4
99
100 With --all, the command can use branch heads as references, so
@@ -115,13 +115,13 @@ closest tagname without any suffix:
115 SEARCH STRATEGY
116 ---------------
117
118 -For each committish supplied "git describe" will first look for
118 +For each committish supplied "git-describe" will first look for
119 a tag which tags exactly that commit. Annotated tags will always
120 be preferred over lightweight tags, and tags with newer dates will
121 always be preferred over tags with older dates. If an exact match
122 is found, its name will be output and searching will stop.
123
124 -If an exact match was not found "git describe" will walk back
124 +If an exact match was not found "git-describe" will walk back
125 through the commit history to locate an ancestor commit which
126 has been tagged. The ancestor's tag will be output along with an
127 abbreviation of the input committish's SHA1.
Documentation/git-diff-files.txt
+1 -1
@@ -8,7 +8,7 @@ git-diff-files - Compares files in the working tree and the index
8
9 SYNOPSIS
10 --------
11 -'git-diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...]
11 +'git diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...]
12
13 DESCRIPTION
14 -----------
Documentation/git-diff-index.txt
+6 -6
@@ -8,7 +8,7 @@ git-diff-index - Compares content and mode of blobs between the index and reposi
8
9 SYNOPSIS
10 --------
11 -'git-diff-index' [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
11 +'git diff-index' [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
12
13 DESCRIPTION
14 -----------
@@ -57,20 +57,20 @@ some files in the index and are ready to commit. You want to see exactly
57 *what* you are going to commit, without having to write a new tree
58 object and compare it that way, and to do that, you just do
59
60 - git-diff-index --cached HEAD
60 + git diff-index --cached HEAD
61
62 Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
63 done an "git-update-index" to make that effective in the index file.
64 -"git-diff-files" wouldn't show anything at all, since the index file
64 +"git diff-files" wouldn't show anything at all, since the index file
65 matches my working directory. But doing a "git-diff-index" does:
66
67 - torvalds@ppc970:~/git> git-diff-index --cached HEAD
67 + torvalds@ppc970:~/git> git diff-index --cached HEAD
68 -100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
69 +100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
70
71 You can see easily that the above is a rename.
72
73 -In fact, "git-diff-index --cached" *should* always be entirely equivalent to
73 +In fact, "git diff-index --cached" *should* always be entirely equivalent to
74 actually doing a "git-write-tree" and comparing that. Except this one is much
75 nicer for the case where you just want to check where you are.
76
@@ -98,7 +98,7 @@ show that. So let's say that you have edited `kernel/sched.c`, but
98 have not actually done a "git-update-index" on it yet - there is no
99 "object" associated with the new state, and you get:
100
101 - torvalds@ppc970:~/v2.6/linux> git-diff-index HEAD
101 + torvalds@ppc970:~/v2.6/linux> git diff-index HEAD
102 *100644->100664 blob 7476bb......->000000...... kernel/sched.c
103
104 i.e., it shows that the tree has changed, and that `kernel/sched.c` has is
Documentation/git-diff-tree.txt
+4 -4
@@ -9,7 +9,7 @@ git-diff-tree - Compares the content and mode of blobs found via two tree object
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
12 +'git diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
13 [-t] [-r] [-c | --cc] [--root] [<common diff options>]
14 <tree-ish> [<tree-ish>] [<path>...]
15
@@ -112,13 +112,13 @@ Limiting Output
112 If you're only interested in differences in a subset of files, for
113 example some architecture-specific files, you might do:
114
115 - git-diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64
115 + git diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64
116
117 and it will only show you what changed in those two directories.
118
119 Or if you are searching for what changed in just `kernel/sched.c`, just do
120
121 - git-diff-tree -r <tree-ish> <tree-ish> kernel/sched.c
121 + git diff-tree -r <tree-ish> <tree-ish> kernel/sched.c
122
123 and it will ignore all differences to other files.
124
@@ -129,7 +129,7 @@ so it can be used to name subdirectories.
129
130 An example of normal usage is:
131
132 - torvalds@ppc970:~/git> git-diff-tree 5319e4......
132 + torvalds@ppc970:~/git> git diff-tree 5319e4......
133 *100664->100664 blob ac348b.......->a01513....... git-fsck-objects.c
134
135 which tells you that the last commit changed just one file (it's from
Documentation/git-diff.txt
+9 -9
@@ -8,14 +8,14 @@ git-diff - Show changes between commits, commit and working tree, etc
8
9 SYNOPSIS
10 --------
11 -'git-diff' [<common diff options>] <commit>{0,2} [--] [<path>...]
11 +'git diff' [<common diff options>] <commit>{0,2} [--] [<path>...]
12
13 DESCRIPTION
14 -----------
15 Show changes between two trees, a tree and the working tree, a
16 tree and the index file, or the index file and the working tree.
17
18 -'git-diff' [--options] [--] [<path>...]::
18 +'git diff' [--options] [--] [<path>...]::
19
20 This form is to view the changes you made relative to
21 the index (staging area for the next commit). In other
@@ -27,14 +27,14 @@ If exactly two paths are given, and at least one is untracked,
27 compare the two files / directories. This behavior can be
28 forced by --no-index.
29
30 -'git-diff' [--options] --cached [<commit>] [--] [<path>...]::
30 +'git diff' [--options] --cached [<commit>] [--] [<path>...]::
31
32 This form is to view the changes you staged for the next
33 commit relative to the named <commit>. Typically you
34 would want comparison with the latest commit, so if you
35 do not give <commit>, it defaults to HEAD.
36
37 -'git-diff' [--options] <commit> [--] [<path>...]::
37 +'git diff' [--options] <commit> [--] [<path>...]::
38
39 This form is to view the changes you have in your
40 working tree relative to the named <commit>. You can
@@ -42,23 +42,23 @@ forced by --no-index.
42 branch name to compare with the tip of a different
43 branch.
44
45 -'git-diff' [--options] <commit> <commit> [--] [<path>...]::
45 +'git diff' [--options] <commit> <commit> [--] [<path>...]::
46
47 This is to view the changes between two arbitrary
48 <commit>.
49
50 -'git-diff' [--options] <commit>..<commit> [--] [<path>...]::
50 +'git diff' [--options] <commit>..<commit> [--] [<path>...]::
51
52 This is synonymous to the previous form. If <commit> on
53 one side is omitted, it will have the same effect as
54 using HEAD instead.
55
56 -'git-diff' [--options] <commit>\...<commit> [--] [<path>...]::
56 +'git diff' [--options] <commit>\...<commit> [--] [<path>...]::
57
58 This form is to view the changes on the branch containing
59 and up to the second <commit>, starting at a common ancestor
60 - of both <commit>. "git-diff A\...B" is equivalent to
61 - "git-diff $(git-merge-base A B) B". You can omit any one
60 + of both <commit>. "git diff A\...B" is equivalent to
61 + "git diff $(git-merge-base A B) B". You can omit any one
62 of <commit>, which has the same effect as using HEAD instead.
63
64 Just in case if you are doing something exotic, it should be
Documentation/git-fast-export.txt
+1 -1
@@ -8,7 +8,7 @@ git-fast-export - Git data exporter
8
9 SYNOPSIS
10 --------
11 -'git-fast-export [options]' | 'git-fast-import'
11 +'git fast-export [options]' | 'git fast-import'
12
13 DESCRIPTION
14 -----------
Documentation/git-fast-import.txt
+4 -4
@@ -8,7 +8,7 @@ git-fast-import - Backend for fast Git data importers
8
9 SYNOPSIS
10 --------
11 -frontend | 'git-fast-import' [options]
11 +frontend | 'git fast-import' [options]
12
13 DESCRIPTION
14 -----------
@@ -126,7 +126,7 @@ Parallel Operation
126 ------------------
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.
@@ -803,7 +803,7 @@ Callers may wish to process the output through a tool such as sed to
803 remove the leading part of the line, for example:
804
805 ====
806 - frontend | git-fast-import | sed 's/^progress //'
806 + frontend | git fast-import | sed 's/^progress //'
807 ====
808
809 Placing a `progress` command immediately after a `checkpoint` will
@@ -851,7 +851,7 @@ An example crash:
851 M 777 inline bob
852 END_OF_INPUT
853
854 - $ git-fast-import <in
854 + $ git fast-import <in
855 fatal: Corrupt mode: M 777 inline bob
856 fast-import: dumping crash report to .git/fast_import_crash_8434
857
Documentation/git-fetch-pack.txt
+1 -1
@@ -8,7 +8,7 @@ git-fetch-pack - Receive missing objects from another repository
8
9 SYNOPSIS
10 --------
11 -'git-fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>...]
11 +'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>...]
12
13 DESCRIPTION
14 -----------
Documentation/git-fetch.txt
+2 -2
@@ -8,7 +8,7 @@ git-fetch - Download objects and refs from another repository
8
9 SYNOPSIS
10 --------
11 -'git-fetch' <options> <repository> <refspec>...
11 +'git fetch' <options> <repository> <refspec>...
12
13
14 DESCRIPTION
@@ -18,7 +18,7 @@ the objects necessary to complete them.
18
19 The ref names and their object names of fetched refs are stored
20 in `.git/FETCH_HEAD`. This information is left for a later merge
21 -operation done by "git merge".
21 +operation done by "git-merge".
22
23 When <refspec> stores the fetched result in tracking branches,
24 the tags that point at these branches are automatically
Documentation/git-filter-branch.txt
+2 -2
@@ -8,7 +8,7 @@ git-filter-branch - Rewrite branches
8 SYNOPSIS
9 --------
10 [verse]
11 -'git-filter-branch' [--env-filter <command>] [--tree-filter <command>]
11 +'git filter-branch' [--env-filter <command>] [--tree-filter <command>]
12 [--index-filter <command>] [--parent-filter <command>]
13 [--msg-filter <command>] [--commit-filter <command>]
14 [--tag-name-filter <command>] [--subdirectory-filter <directory>]
@@ -266,7 +266,7 @@ git filter-branch --msg-filter '
266
267 To restrict rewriting to only part of the history, specify a revision
268 range in addition to the new branch name. The new branch name will
269 -point to the top-most revision that a 'git rev-list' of this range
269 +point to the top-most revision that a 'git-rev-list' of this range
270 will print.
271
272 *NOTE* the changes introduced by the commits, and which are not reverted
Documentation/git-fmt-merge-msg.txt
+2 -2
@@ -9,8 +9,8 @@ git-fmt-merge-msg - Produce a merge commit message
9 SYNOPSIS
10 --------
11 [verse]
12 -git-fmt-merge-msg [--log | --no-log] <$GIT_DIR/FETCH_HEAD
13 -git-fmt-merge-msg [--log | --no-log] -F <file>
12 +git fmt-merge-msg [--log | --no-log] <$GIT_DIR/FETCH_HEAD
13 +git fmt-merge-msg [--log | --no-log] -F <file>
14
15 DESCRIPTION
16 -----------
Documentation/git-for-each-ref.txt
+4 -4
@@ -8,7 +8,7 @@ git-for-each-ref - Output information on each ref
8 SYNOPSIS
9 --------
10 [verse]
11 -'git-for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl]
11 +'git for-each-ref' [--count=<count>] [--shell|--perl|--python|--tcl]
12 [--sort=<key>]\* [--format=<format>] [<pattern>...]
13
14 DESCRIPTION
@@ -119,7 +119,7 @@ An example directly producing formatted text. Show the most recent
119 ------------
120 #!/bin/sh
121
122 -git-for-each-ref --count=3 --sort='-*authordate' \
122 +git for-each-ref --count=3 --sort='-*authordate' \
123 --format='From: %(*authorname) %(*authoremail)
124 Subject: %(*subject)
125 Date: %(*authordate)
@@ -135,7 +135,7 @@ demonstrating the use of --shell. List the prefixes of all heads::
135 ------------
136 #!/bin/sh
137
138 -git-for-each-ref --shell --format="ref=%(refname)" refs/heads | \
138 +git for-each-ref --shell --format="ref=%(refname)" refs/heads | \
139 while read entry
140 do
141 eval "$entry"
@@ -189,7 +189,7 @@ Its message reads as:
189 fi
190 '
191
192 -eval=`git-for-each-ref --shell --format="$fmt" \
192 +eval=`git for-each-ref --shell --format="$fmt" \
193 --sort='*objecttype' \
194 --sort=-taggerdate \
195 refs/tags`
Documentation/git-format-patch.txt
+1 -1
@@ -9,7 +9,7 @@ git-format-patch - Prepare patches for e-mail submission
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-format-patch' [-k] [-o <dir> | --stdout] [--thread]
12 +'git format-patch' [-k] [-o <dir> | --stdout] [--thread]
13 [--attach[=<boundary>] | --inline[=<boundary>]]
14 [-s | --signoff] [<common diff options>]
15 [-n | --numbered | -N | --no-numbered]
Documentation/git-fsck-objects.txt
+1 -1
@@ -8,7 +8,7 @@ git-fsck-objects - Verifies the connectivity and validity of the objects in the
8
9 SYNOPSIS
10 --------
11 -'git-fsck-objects' ...
11 +'git fsck-objects' ...
12
13 DESCRIPTION
14 -----------
Documentation/git-fsck.txt
+2 -2
@@ -9,7 +9,7 @@ git-fsck - Verifies the connectivity and validity of the objects in the database
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
12 +'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
13 [--full] [--strict] [--verbose] [--lost-found] [<object>*]
14
15 DESCRIPTION
@@ -79,7 +79,7 @@ that aren't readable from any of the specified head nodes.
79
80 So for example
81
82 - git-fsck --unreachable HEAD $(cat .git/refs/heads/*)
82 + git fsck --unreachable HEAD $(cat .git/refs/heads/*)
83
84 will do quite a _lot_ of verification on the tree. There are a few
85 extra validity tests to be added (make sure that tree objects are
Documentation/git-gc.txt
+3 -3
@@ -8,7 +8,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository
8
9 SYNOPSIS
10 --------
11 -'git-gc' [--aggressive] [--auto] [--quiet]
11 +'git gc' [--aggressive] [--auto] [--quiet]
12
13 DESCRIPTION
14 -----------
@@ -41,7 +41,7 @@ OPTIONS
41 few hundred changesets or so.
42
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.
@@ -89,7 +89,7 @@ how long records of conflicted merge you have not resolved are
89 kept. This defaults to 15 days.
90
91 The optional configuration variable 'gc.packrefs' determines if
92 -`git gc` runs `git-pack-refs`. This can be set to "nobare" to enable
92 +`git-gc` runs `git-pack-refs`. This can be set to "nobare" to enable
93 it within all non-bare repos or it can be set to a boolean value.
94 This defaults to true.
95
Documentation/git-get-tar-commit-id.txt
+1 -1
@@ -8,7 +8,7 @@ git-get-tar-commit-id - Extract commit ID from an archive created using git-arch
8
9 SYNOPSIS
10 --------
11 -'git-get-tar-commit-id' < <tarfile>
11 +'git get-tar-commit-id' < <tarfile>
12
13
14 DESCRIPTION
Documentation/git-grep.txt
+1 -1
@@ -9,7 +9,7 @@ git-grep - Print lines matching a pattern
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-grep' [--cached]
12 +'git grep' [--cached]
13 [-a | --text] [-I] [-i | --ignore-case] [-w | --word-regexp]
14 [-v | --invert-match] [-h|-H] [--full-name]
15 [-E | --extended-regexp] [-G | --basic-regexp]
Documentation/git-hash-object.txt
+1 -1
@@ -8,7 +8,7 @@ git-hash-object - Compute object ID and optionally creates a blob from a file
8
9 SYNOPSIS
10 --------
11 -'git-hash-object' [-t <type>] [-w] [--stdin | --stdin-paths] [--] <file>...
11 +'git hash-object' [-t <type>] [-w] [--stdin | --stdin-paths] [--] <file>...
12
13 DESCRIPTION
14 -----------
Documentation/git-http-fetch.txt
+1 -1
@@ -8,7 +8,7 @@ git-http-fetch - Download from a remote git repository via HTTP
8
9 SYNOPSIS
10 --------
11 -'git-http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] <commit> <url>
11 +'git http-fetch' [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] <commit> <url>
12
13 DESCRIPTION
14 -----------
Documentation/git-http-push.txt
+1 -1
@@ -8,7 +8,7 @@ git-http-push - Push objects over HTTP/DAV to another repository
8
9 SYNOPSIS
10 --------
11 -'git-http-push' [--all] [--dry-run] [--force] [--verbose] <url> <ref> [<ref>...]
11 +'git http-push' [--all] [--dry-run] [--force] [--verbose] <url> <ref> [<ref>...]
12
13 DESCRIPTION
14 -----------
Documentation/git-imap-send.txt
+2 -2
@@ -8,7 +8,7 @@ git-imap-send - Dump a mailbox from stdin into an imap folder
8
9 SYNOPSIS
10 --------
11 -'git-imap-send'
11 +'git imap-send'
12
13
14 DESCRIPTION
@@ -20,7 +20,7 @@ files directly.
20
21 Typical usage is something like:
22
23 -git-format-patch --signoff --stdout --attach origin | git-imap-send
23 +git format-patch --signoff --stdout --attach origin | git imap-send
24
25
26 CONFIGURATION
Documentation/git-index-pack.txt
+2 -2
@@ -9,8 +9,8 @@ git-index-pack - Build pack index file for an existing packed archive
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-index-pack' [-v] [-o <index-file>] <pack-file>
13 -'git-index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
12 +'git index-pack' [-v] [-o <index-file>] <pack-file>
13 +'git index-pack' --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
14 [<pack-file>]
15
16
Documentation/git-init-db.txt
+1 -1
@@ -8,7 +8,7 @@ git-init-db - Creates an empty git repository
8
9 SYNOPSIS
10 --------
11 -'git-init-db' [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]
11 +'git init-db' [-q | --quiet] [--template=<template_directory>] [--shared[=<permissions>]]
12
13
14 DESCRIPTION
Documentation/git-init.txt
+3 -3
@@ -8,7 +8,7 @@ git-init - Create an empty git repository or reinitialize an existing one
8
9 SYNOPSIS
10 --------
11 -'git-init' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]]
11 +'git init' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]]
12
13
14 OPTIONS
@@ -105,8 +105,8 @@ Start a new git repository for an existing code base::
105 +
106 ----------------
107 $ cd /path/to/my/codebase
108 -$ git-init <1>
109 -$ git-add . <2>
108 +$ git init <1>
109 +$ git add . <2>
110 ----------------
111 +
112 <1> prepare /path/to/my/codebase/.git directory
Documentation/git-instaweb.txt
+2 -2
@@ -8,9 +8,9 @@ git-instaweb - Instantly browse your working repository in gitweb
8 SYNOPSIS
9 --------
10 [verse]
11 -'git-instaweb' [--local] [--httpd=<httpd>] [--port=<port>]
11 +'git instaweb' [--local] [--httpd=<httpd>] [--port=<port>]
12 [--browser=<browser>]
13 -'git-instaweb' [--start] [--stop] [--restart]
13 +'git instaweb' [--start] [--stop] [--restart]
14
15 DESCRIPTION
16 -----------
Documentation/git-log.txt
+1 -1
@@ -8,7 +8,7 @@ git-log - Show commit logs
8
9 SYNOPSIS
10 --------
11 -'git-log' <option>...
11 +'git log' <option>...
12
13 DESCRIPTION
14 -----------
Documentation/git-lost-found.txt
+1 -1
@@ -7,7 +7,7 @@ git-lost-found - Recover lost refs that luckily have not yet been pruned
7
8 SYNOPSIS
9 --------
10 -'git-lost-found'
10 +'git lost-found'
11
12 DESCRIPTION
13 -----------
Documentation/git-ls-files.txt
+1 -1
@@ -9,7 +9,7 @@ git-ls-files - Show information about files in the index and the working tree
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-ls-files' [-z] [-t] [-v]
12 +'git ls-files' [-z] [-t] [-v]
13 (--[cached|deleted|others|ignored|stage|unmerged|killed|modified])\*
14 (-[c|d|o|i|s|u|k|m])\*
15 [-x <pattern>|--exclude=<pattern>]
Documentation/git-ls-remote.txt
+1 -1
@@ -9,7 +9,7 @@ git-ls-remote - List references in a remote repository
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-ls-remote' [--heads] [--tags] [-u <exec> | --upload-pack <exec>]
12 +'git ls-remote' [--heads] [--tags] [-u <exec> | --upload-pack <exec>]
13 <repository> <refs>...
14
15 DESCRIPTION
Documentation/git-ls-tree.txt
+1 -1
@@ -9,7 +9,7 @@ git-ls-tree - List the contents of a tree object
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-ls-tree' [-d] [-r] [-t] [-l] [-z]
12 +'git ls-tree' [-d] [-r] [-t] [-l] [-z]
13 [--name-only] [--name-status] [--full-name] [--abbrev=[<n>]]
14 <tree-ish> [paths...]
15
Documentation/git-mailinfo.txt
+2 -2
@@ -8,7 +8,7 @@ git-mailinfo - Extracts patch and authorship from a single e-mail message
8
9 SYNOPSIS
10 --------
11 -'git-mailinfo' [-k] [-u | --encoding=<encoding>] <msg> <patch>
11 +'git mailinfo' [-k] [-u | --encoding=<encoding>] <msg> <patch>
12
13
14 DESCRIPTION
@@ -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.
34
35 -u::
36 The commit log message, author name and author email are
Documentation/git-mailsplit.txt
+1 -1
@@ -7,7 +7,7 @@ git-mailsplit - Simple UNIX mbox splitter program
7
8 SYNOPSIS
9 --------
10 -'git-mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>|<Maildir>...]
10 +'git mailsplit' [-b] [-f<nn>] [-d<prec>] -o<directory> [--] [<mbox>|<Maildir>...]
11
12 DESCRIPTION
13 -----------
Documentation/git-merge-base.txt
+2 -2
@@ -8,13 +8,13 @@ git-merge-base - Find as good common ancestors as possible for a merge
8
9 SYNOPSIS
10 --------
11 -'git-merge-base' [--all] <commit> <commit>
11 +'git merge-base' [--all] <commit> <commit>
12
13 DESCRIPTION
14 -----------
15
16 "git-merge-base" finds as good a common ancestor as possible between
17 -the two commits. That is, given two commits A and B 'git-merge-base A
17 +the two commits. That is, given two commits A and B 'git merge-base A
18 B' will output a commit which is reachable from both A and B through
19 the parent relationship.
20
Documentation/git-merge-file.txt
+2 -2
@@ -9,7 +9,7 @@ git-merge-file - Run a three-way file merge
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
12 +'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]
13 [-p|--stdout] [-q|--quiet] <current-file> <base-file> <other-file>
14
15
@@ -51,7 +51,7 @@ OPTIONS
51 This option may be given up to three times, and
52 specifies labels to be used in place of the
53 corresponding file names in conflict reports. That is,
54 - `git-merge-file -L x -L y -L z a b c` generates output that
54 + `git merge-file -L x -L y -L z a b c` generates output that
55 looks like it came from files x, y and z instead of
56 from files a, b and c.
57
Documentation/git-merge-index.txt
+3 -3
@@ -8,7 +8,7 @@ git-merge-index - Run a merge for files needing merging
8
9 SYNOPSIS
10 --------
11 -'git-merge-index' [-o] [-q] <merge-program> (-a | [--] <file>\*)
11 +'git merge-index' [-o] [-q] <merge-program> (-a | [--] <file>\*)
12
13 DESCRIPTION
14 -----------
@@ -53,7 +53,7 @@ original is first. But the argument order to the 3-way merge program
53
54 Examples:
55
56 - torvalds@ppc970:~/merge-test> git-merge-index cat MM
56 + torvalds@ppc970:~/merge-test> git merge-index cat MM
57 This is MM from the original tree. # original
58 This is modified MM in the branch A. # merge1
59 This is modified MM in the branch B. # merge2
@@ -61,7 +61,7 @@ Examples:
61
62 or
63
64 - torvalds@ppc970:~/merge-test> git-merge-index cat AA MM
64 + torvalds@ppc970:~/merge-test> git merge-index cat AA MM
65 cat: : No such file or directory
66 This is added AA in the branch A.
67 This is added AA in the branch B.
Documentation/git-merge-tree.txt
+1 -1
@@ -8,7 +8,7 @@ git-merge-tree - Show three-way merge without touching index
8
9 SYNOPSIS
10 --------
11 -'git-merge-tree' <base-tree> <branch1> <branch2>
11 +'git merge-tree' <base-tree> <branch1> <branch2>
12
13 DESCRIPTION
14 -----------
Documentation/git-merge.txt
+5 -5
@@ -9,9 +9,9 @@ git-merge - Join two or more development histories together
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
12 +'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
13 [-m <msg>] <remote> <remote>...
14 -'git-merge' <msg> HEAD <remote>...
14 +'git merge' <msg> HEAD <remote>...
15
16 DESCRIPTION
17 -----------
@@ -60,7 +60,7 @@ A merge is always between the current `HEAD` and one or more
60 commits (usually, branch head or tag), and the index file must
61 exactly match the
62 tree of `HEAD` commit (i.e. the contents of the last commit) when
63 -it happens. In other words, `git-diff --cached HEAD` must
63 +it happens. In other words, `git diff --cached HEAD` must
64 report no changes.
65
66 [NOTE]
@@ -128,7 +128,7 @@ When there are conflicts, these things happen:
128 3. For conflicting paths, the index file records up to three
129 versions; stage1 stores the version from the common ancestor,
130 stage2 from `HEAD`, and stage3 from the remote branch (you
131 - can inspect the stages with `git-ls-files -u`). The working
131 + can inspect the stages with `git ls-files -u`). The working
132 tree files have the result of "merge" program; i.e. 3-way
133 merge result with familiar conflict markers `<<< === >>>`.
134
@@ -144,7 +144,7 @@ After seeing a conflict, you can do two things:
144 up working tree changes made by 2. and 3.; `git-reset` can
145 be used for this.
146
147 - * Resolve the conflicts. `git-diff` would report only the
147 + * Resolve the conflicts. `git diff` would report only the
148 conflicting paths because of the above 2. and 3.. Edit the
149 working tree files into a desirable shape, `git-add` or `git-rm`
150 them, to make the index file contain what the merge result
Documentation/git-mergetool.txt
+8 -8
@@ -7,7 +7,7 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
7
8 SYNOPSIS
9 --------
10 -'git-mergetool' [--tool=<tool>] [<file>]...
10 +'git mergetool' [--tool=<tool>] [<file>]...
11
12 DESCRIPTION
13 -----------
@@ -17,7 +17,7 @@ merge conflicts. It is typically run after linkgit:git-merge[1].
17
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.
22
23 OPTIONS
@@ -27,23 +27,23 @@ OPTIONS
27 Valid merge tools are:
28 kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
29 +
30 -If a merge resolution program is not specified, `git mergetool`
30 +If a merge resolution program is not specified, `git-mergetool`
31 will use the configuration variable `merge.tool`. If the
32 -configuration variable `merge.tool` is not set, `git mergetool`
32 +configuration variable `merge.tool` is not set, `git-mergetool`
33 will pick a suitable default.
34 +
35 You can explicitly provide a full path to the tool by setting the
36 configuration variable `mergetool.<tool>.path`. For example, you
37 can configure the absolute path to kdiff3 by setting
38 -`mergetool.kdiff3.path`. Otherwise, `git mergetool` assumes the
38 +`mergetool.kdiff3.path`. Otherwise, `git-mergetool` assumes the
39 tool is available in PATH.
40 +
41 Instead of running one of the known merge tool programs
42 -`git mergetool` can be customized to run an alternative program
42 +`git-mergetool` can be customized to run an alternative program
43 by specifying the command line to invoke in a configration
44 variable `mergetool.<tool>.cmd`.
45 +
46 -When `git mergetool` is invoked with this tool (either through the
46 +When `git-mergetool` is invoked with this tool (either through the
47 `-t` or `--tool` option or the `merge.tool` configuration
48 variable) the configured command line will be invoked with `$BASE`
49 set to the name of a temporary file containing the common base for
@@ -57,7 +57,7 @@ merge resolution.
57 If the custom merge tool correctly indicates the success of a
58 merge resolution with its exit code then the configuration
59 variable `mergetool.<tool>.trustExitCode` can be set to `true`.
60 -Otherwise, `git mergetool` will prompt the user to indicate the
60 +Otherwise, `git-mergetool` will prompt the user to indicate the
61 success of the resolution after the custom tool has exited.
62
63 Author
Documentation/git-mktag.txt
+1 -1
@@ -8,7 +8,7 @@ git-mktag - Creates a tag object
8
9 SYNOPSIS
10 --------
11 -'git-mktag' < signature_file
11 +'git mktag' < signature_file
12
13 DESCRIPTION
14 -----------
Documentation/git-mktree.txt
+1 -1
@@ -8,7 +8,7 @@ git-mktree - Build a tree-object from ls-tree formatted text
8
9 SYNOPSIS
10 --------
11 -'git-mktree' [-z]
11 +'git mktree' [-z]
12
13 DESCRIPTION
14 -----------
Documentation/git-mv.txt
+3 -3
@@ -8,14 +8,14 @@ git-mv - Move or rename a file, a directory, or a symlink
8
9 SYNOPSIS
10 --------
11 -'git-mv' <options>... <args>...
11 +'git mv' <options>... <args>...
12
13 DESCRIPTION
14 -----------
15 This script is used to move or rename a file, directory or symlink.
16
17 - git-mv [-f] [-n] <source> <destination>
18 - git-mv [-f] [-n] [-k] <source> ... <destination directory>
17 + git mv [-f] [-n] <source> <destination>
18 + git mv [-f] [-n] [-k] <source> ... <destination directory>
19
20 In the first form, it renames <source>, which must exist and be either
21 a file, symlink or directory, to <destination>.
Documentation/git-name-rev.txt
+1 -1
@@ -9,7 +9,7 @@ git-name-rev - Find symbolic names for given revs
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-name-rev' [--tags] [--refs=<pattern>]
12 +'git name-rev' [--tags] [--refs=<pattern>]
13 ( --all | --stdin | <committish>... )
14
15 DESCRIPTION
Documentation/git-pack-objects.txt
+1 -1
@@ -9,7 +9,7 @@ git-pack-objects - Create a packed archive of objects
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-pack-objects' [-q] [--no-reuse-delta] [--delta-base-offset] [--non-empty]
12 +'git pack-objects' [-q] [--no-reuse-delta] [--delta-base-offset] [--non-empty]
13 [--local] [--incremental] [--window=N] [--depth=N] [--all-progress]
14 [--revs [--unpacked | --all]*] [--stdout | base-name] < object-list
15
Documentation/git-pack-redundant.txt
+3 -3
@@ -8,7 +8,7 @@ git-pack-redundant - Find redundant pack files
8
9 SYNOPSIS
10 --------
11 -'git-pack-redundant' [ --verbose ] [ --alt-odb ] < --all | .pack filename ... >
11 +'git pack-redundant' [ --verbose ] [ --alt-odb ] < --all | .pack filename ... >
12
13 DESCRIPTION
14 -----------
@@ -21,8 +21,8 @@ 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.
23
24 -git-fsck --full --unreachable | cut -d ' ' -f3 | \
25 -git-pack-redundant --all | xargs rm
24 +git fsck --full --unreachable | cut -d ' ' -f3 | \
25 +git pack-redundant --all | xargs rm
26
27 OPTIONS
28 -------
Documentation/git-pack-refs.txt
+2 -2
@@ -7,7 +7,7 @@ git-pack-refs - Pack heads and tags for efficient repository access
7
8 SYNOPSIS
9 --------
10 -'git-pack-refs' [--all] [--no-prune]
10 +'git pack-refs' [--all] [--no-prune]
11
12 DESCRIPTION
13 -----------
@@ -31,7 +31,7 @@ Subsequent updates to branches always creates new file under
31
32 A recommended practice to deal with a repository with too many
33 refs is to pack its refs with `--all --prune` once, and
34 -occasionally run `git-pack-refs \--prune`. Tags are by
34 +occasionally run `git pack-refs \--prune`. Tags are by
35 definition stationary and are not expected to change. Branch
36 heads will be packed with the initial `pack-refs --all`, but
37 only the currently active branch heads will become unpacked,
Documentation/git-patch-id.txt
+1 -1
@@ -7,7 +7,7 @@ git-patch-id - Compute unique ID for a patch
7
8 SYNOPSIS
9 --------
10 -'git-patch-id' < <patch>
10 +'git patch-id' < <patch>
11
12 DESCRIPTION
13 -----------
Documentation/git-peek-remote.txt
+1 -1
@@ -8,7 +8,7 @@ git-peek-remote - List the references in a remote repository
8
9 SYNOPSIS
10 --------
11 -'git-peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory>
11 +'git peek-remote' [--upload-pack=<git-upload-pack>] [<host>:]<directory>
12
13 DESCRIPTION
14 -----------
Documentation/git-prune-packed.txt
+1 -1
@@ -8,7 +8,7 @@ git-prune-packed - Remove extra objects that are already in pack files
8
9 SYNOPSIS
10 --------
11 -'git-prune-packed' [-n] [-q]
11 +'git prune-packed' [-n] [-q]
12
13
14 DESCRIPTION
Documentation/git-prune.txt
+2 -2
@@ -22,7 +22,7 @@ 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`.
26
27 Note that unreachable, packed objects will remain. If this is
28 not desired, see linkgit:git-repack[1].
@@ -53,7 +53,7 @@ borrows from your repository via its
53 `.git/objects/info/alternates`:
54
55 ------------
56 -$ git prune $(cd ../another && $(git-rev-parse --all))
56 +$ git prune $(cd ../another && $(git rev-parse --all))
57 ------------
58
59 Notes
Documentation/git-pull.txt
+1 -1
@@ -8,7 +8,7 @@ git-pull - Fetch from and merge with another repository or a local branch
8
9 SYNOPSIS
10 --------
11 -'git-pull' <options> <repository> <refspec>...
11 +'git pull' <options> <repository> <refspec>...
12
13
14 DESCRIPTION
Documentation/git-push.txt
+1 -1
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
12 +'git push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
13 [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
14
15 DESCRIPTION
Documentation/git-quiltimport.txt
+1 -1
@@ -9,7 +9,7 @@ git-quiltimport - Applies a quilt patchset onto the current branch
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-quiltimport' [--dry-run] [--author <author>] [--patches <dir>]
12 +'git quiltimport' [--dry-run] [--author <author>] [--patches <dir>]
13
14
15 DESCRIPTION
Documentation/git-read-tree.txt
+16 -16
@@ -8,7 +8,7 @@ git-read-tree - Reads tree information into the index
8
9 SYNOPSIS
10 --------
11 -'git-read-tree' (<tree-ish> | [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] [--index-output=<file>] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
11 +'git read-tree' (<tree-ish> | [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] [--index-output=<file>] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
12
13
14 DESCRIPTION
@@ -127,8 +127,8 @@ given pathname, and the contents of the path matches with the tree
127 being read, the stat info from the index is used. (In other words, the
128 index's stat()s take precedence over the merged tree's).
129
130 -That means that if you do a `git-read-tree -m <newtree>` followed by a
131 -`git-checkout-index -f -u -a`, the `git-checkout-index` only checks out
130 +That means that if you do a `git read-tree -m <newtree>` followed by a
131 +`git checkout-index -f -u -a`, the `git-checkout-index` only checks out
132 the stuff that really changed.
133
134 This is used to avoid unnecessary false hits when `git-diff-files` is
@@ -138,7 +138,7 @@ run after `git-read-tree`.
138 Two Tree Merge
139 ~~~~~~~~~~~~~~
140
141 -Typically, this is invoked as `git-read-tree -m $H $M`, where $H
141 +Typically, this is invoked as `git read-tree -m $H $M`, where $H
142 is the head commit of the current repository, and $M is the head
143 of a foreign tree, which is simply ahead of $H (i.e. we are in a
144 fast forward situation).
@@ -151,7 +151,7 @@ the following:
151
152 2. The user wants to fast-forward to $M.
153
154 -In this case, the `git-read-tree -m $H $M` command makes sure
154 +In this case, the `git read-tree -m $H $M` command makes sure
155 that no local change is lost as the result of this "merge".
156 Here are the "carry forward" rules:
157
@@ -198,13 +198,13 @@ operating under the -u flag.
198
199 When this form of git-read-tree returns successfully, you can
200 see what "local changes" you made are carried forward by running
201 -`git-diff-index --cached $M`. Note that this does not
202 -necessarily match `git-diff-index --cached $H` would have
201 +`git diff-index --cached $M`. Note that this does not
202 +necessarily match `git diff-index --cached $H` would have
203 produced before such a two tree merge. This is because of cases
204 18 and 19 --- if you already had the changes in $M (e.g. maybe
205 -you picked it up via e-mail in a patch form), `git-diff-index
205 +you picked it up via e-mail in a patch form), `git diff-index
206 --cached $H` would have told you about the change before this
207 -merge, but it would not show in `git-diff-index --cached $M`
207 +merge, but it would not show in `git diff-index --cached $M`
208 output after two-tree merge.
209
210
@@ -219,7 +219,7 @@ starts out at 1.
219 This means that you can do
220
221 ----------------
222 -$ git-read-tree -m <tree1> <tree2> <tree3>
222 +$ git read-tree -m <tree1> <tree2> <tree3>
223 ----------------
224
225 and you will end up with an index with all of the <tree1> entries in
@@ -304,8 +304,8 @@ commit. To illustrate, suppose you start from what has been
304 committed last to your repository:
305
306 ----------------
307 -$ JC=`git-rev-parse --verify "HEAD^0"`
308 -$ git-checkout-index -f -u -a $JC
307 +$ JC=`git rev-parse --verify "HEAD^0"`
308 +$ git checkout-index -f -u -a $JC
309 ----------------
310
311 You do random edits, without running git-update-index. And then
@@ -313,7 +313,7 @@ you notice that the tip of your "upstream" tree has advanced
313 since you pulled from him:
314
315 ----------------
316 -$ git-fetch git://.... linus
316 +$ git fetch git://.... linus
317 $ LT=`cat .git/FETCH_HEAD`
318 ----------------
319
@@ -323,10 +323,10 @@ added or modified index entries since $JC, and if you haven't,
323 then does the right thing. So with the following sequence:
324
325 ----------------
326 -$ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT
327 -$ git-merge-index git-merge-one-file -a
326 +$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT
327 +$ git merge-index git-merge-one-file -a
328 $ echo "Merge with Linus" | \
329 - git-commit-tree `git-write-tree` -p $JC -p $LT
329 + git commit-tree `git write-tree` -p $JC -p $LT
330 ----------------
331
332 what you would commit is a pure merge between $JC and $LT without
Documentation/git-rebase.txt
+10 -10
@@ -8,11 +8,11 @@ git-rebase - Forward-port local commits to the updated upstream head
8 SYNOPSIS
9 --------
10 [verse]
11 -'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
11 +'git rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
12 [-s <strategy> | --strategy=<strategy>]
13 [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]
14 [--onto <newbase>] <upstream> [<branch>]
15 -'git-rebase' --continue | --skip | --abort
15 +'git rebase' --continue | --skip | --abort
16
17 DESCRIPTION
18 -----------
@@ -52,8 +52,8 @@ Assume the following history exists and the current branch is "topic":
52 From this point, the result of either of the following commands:
53
54
55 - git-rebase master
56 - git-rebase master topic
55 + git rebase master
56 + git rebase master topic
57
58 would be:
59
@@ -68,7 +68,7 @@ followed by `git rebase master`.
68
69 If the upstream branch already contains a change you have made (e.g.,
70 because you mailed a patch which was applied upstream), then that commit
71 -will be skipped. For example, running `git-rebase master` on the
71 +will be skipped. For example, running `git rebase master` on the
72 following history (in which A' and A introduce the same set of changes,
73 but have different committer information):
74
@@ -116,7 +116,7 @@ got merged into more stable 'master' branch, like this:
116
117 We can get this using the following command:
118
119 - git-rebase --onto master next topic
119 + git rebase --onto master next topic
120
121
122 Another example of --onto option is to rebase part of a
@@ -132,7 +132,7 @@ branch. If we have the following situation:
132
133 then the command
134
135 - git-rebase --onto master topicA topicB
135 + git rebase --onto master topicA topicB
136
137 would result in:
138
@@ -155,7 +155,7 @@ the following situation:
155
156 then the command
157
158 - git-rebase --onto topicA~5 topicA~3 topicA
158 + git rebase --onto topicA~5 topicA~3 topicA
159
160 would result in the removal of commits F and G:
161
@@ -168,7 +168,7 @@ part of topicA. Note that the argument to --onto and the <upstream>
168 parameter can be any valid commit-ish.
169
170 In case of conflict, git-rebase will stop at the first problematic commit
171 -and leave conflict markers in the tree. You can use git diff to locate
171 +and leave conflict markers in the tree. You can use git-diff to locate
172 the markers (<<<<<<) and make edits to resolve the conflict. For each
173 file you edit, you need to tell git that the conflict has been resolved,
174 typically this would be done with
@@ -364,7 +364,7 @@ SPLITTING COMMITS
364 -----------------
365
366 In interactive mode, you can mark commits with the action "edit". However,
367 -this does not necessarily mean that 'git rebase' expects the result of this
367 +this does not necessarily mean that 'git-rebase' expects the result of this
368 edit to be exactly one commit. Indeed, you can undo the commit, or you can
369 add other commits. This can be used to split a commit into two:
370
Documentation/git-receive-pack.txt
+5 -5
@@ -8,7 +8,7 @@ git-receive-pack - Receive what is pushed into the repository
8
9 SYNOPSIS
10 --------
11 -'git-receive-pack' <directory>
11 +'git receive-pack' <directory>
12
13 DESCRIPTION
14 -----------
@@ -111,10 +111,10 @@ ref listing the commits pushed to the repository:
111 if expr "$oval" : '0*$' >/dev/null
112 then
113 echo "Created a new ref, with the following commits:"
114 - git-rev-list --pretty "$nval"
114 + git rev-list --pretty "$nval"
115 else
116 echo "New commits:"
117 - git-rev-list --pretty "$nval" "^$oval"
117 + git rev-list --pretty "$nval" "^$oval"
118 fi |
119 mail -s "Changes to ref $ref" commit-list@mydomain
120 done
@@ -140,11 +140,11 @@ The exit code from this hook invocation is ignored; the only thing
140 left for git-receive-pack to do at that point is to exit itself
141 anyway.
142
143 -This hook can be used, for example, to run "git-update-server-info"
143 +This hook can be used, for example, to run "git update-server-info"
144 if the repository is packed and is served via a dumb transport.
145
146 #!/bin/sh
147 - exec git-update-server-info
147 + exec git update-server-info
148
149
150 SEE ALSO
Documentation/git-relink.txt
+1 -1
@@ -7,7 +7,7 @@ git-relink - Hardlink common objects in local repositories
7
8 SYNOPSIS
9 --------
10 -'git-relink' [--safe] <dir> [<dir>]\* <master_dir>
10 +'git relink' [--safe] <dir> [<dir>]\* <master_dir>
11
12 DESCRIPTION
13 -----------
Documentation/git-remote.txt
+6 -6
@@ -9,12 +9,12 @@ git-remote - manage set of tracked repositories
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-remote' [-v | --verbose]
13 -'git-remote' add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
14 -'git-remote' rm <name>
15 -'git-remote' show [-n] <name>
16 -'git-remote' prune [-n | --dry-run] <name>
17 -'git-remote' update [group]
12 +'git remote' [-v | --verbose]
13 +'git remote' add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
14 +'git remote' rm <name>
15 +'git remote' show [-n] <name>
16 +'git remote' prune [-n | --dry-run] <name>
17 +'git remote' update [group]
18
19 DESCRIPTION
20 -----------
Documentation/git-repack.txt
+5 -5
@@ -8,7 +8,7 @@ git-repack - Pack unpacked objects in a repository
8
9 SYNOPSIS
10 --------
11 -'git-repack' [-a] [-A] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]
11 +'git repack' [-a] [-A] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]
12
13 DESCRIPTION
14 -----------
@@ -55,20 +55,20 @@ OPTIONS
55 Also runs linkgit:git-prune-packed[1].
56
57 -l::
58 - Pass the `--local` option to `git pack-objects`, see
58 + Pass the `--local` option to `git-pack-objects`, see
59 linkgit:git-pack-objects[1].
60
61 -f::
62 - Pass the `--no-reuse-delta` option to `git pack-objects`, see
62 + Pass the `--no-reuse-delta` option to `git-pack-objects`, see
63 linkgit:git-pack-objects[1].
64
65 -q::
66 - Pass the `-q` option to `git pack-objects`, see
66 + Pass the `-q` option to `git-pack-objects`, see
67 linkgit:git-pack-objects[1].
68
69 -n::
70 Do not update the server information with
71 - `git update-server-info`. This option skips
71 + `git-update-server-info`. This option skips
72 updating local catalog files needed to publish
73 this repository (or a direct copy of it)
74 over HTTP or FTP. See gitlink:git-update-server-info[1].
Documentation/git-repo-config.txt
+1 -1
@@ -8,7 +8,7 @@ git-repo-config - Get and set repository or global options
8
9 SYNOPSIS
10 --------
11 -'git-repo-config' ...
11 +'git repo-config' ...
12
13
14 DESCRIPTION
Documentation/git-request-pull.txt
+1 -1
@@ -7,7 +7,7 @@ git-request-pull - Generates a summary of pending changes
7
8 SYNOPSIS
9 --------
10 -'git-request-pull' <start> <url> [<end>]
10 +'git request-pull' <start> <url> [<end>]
11
12 DESCRIPTION
13 -----------
Documentation/git-rerere.txt
+2 -2
@@ -7,7 +7,7 @@ git-rerere - Reuse recorded resolution of conflicted merges
7
8 SYNOPSIS
9 --------
10 -'git-rerere' [clear|diff|status|gc]
10 +'git rerere' [clear|diff|status|gc]
11
12 DESCRIPTION
13 -----------
@@ -198,7 +198,7 @@ you could run `git rebase master topic`, to keep yourself
198 up-to-date even before your topic is ready to be sent upstream.
199 This would result in falling back to three-way merge, and it
200 would conflict the same way the test merge you resolved earlier.
201 -`git-rerere` is run by `git rebase` to help you resolve this
201 +`git-rerere` is run by `git-rebase` to help you resolve this
202 conflict.
203
204
Documentation/git-rev-list.txt
+5 -5
@@ -59,7 +59,7 @@ stop at that point. Their parents are implied. Thus the following
59 command:
60
61 -----------------------------------------------------------------------
62 - $ git-rev-list foo bar ^baz
62 + $ git rev-list foo bar ^baz
63 -----------------------------------------------------------------------
64
65 means "list all the commits which are included in 'foo' and 'bar', but
@@ -70,8 +70,8 @@ short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of
70 the following may be used interchangeably:
71
72 -----------------------------------------------------------------------
73 - $ git-rev-list origin..HEAD
74 - $ git-rev-list HEAD ^origin
73 + $ git rev-list origin..HEAD
74 + $ git rev-list HEAD ^origin
75 -----------------------------------------------------------------------
76
77 Another special notation is "'<commit1>'...'<commit2>'" which is useful
@@ -79,8 +79,8 @@ for merges. The resulting set of commits is the symmetric difference
79 between the two operands. The following two commands are equivalent:
80
81 -----------------------------------------------------------------------
82 - $ git-rev-list A B --not $(git-merge-base --all A B)
83 - $ git-rev-list A...B
82 + $ git rev-list A B --not $(git merge-base --all A B)
83 + $ git rev-list A...B
84 -----------------------------------------------------------------------
85
86 linkgit:git-rev-list[1] is a very essential git program, since it
Documentation/git-rev-parse.txt
+3 -3
@@ -8,7 +8,7 @@ git-rev-parse - Pick out and massage parameters
8
9 SYNOPSIS
10 --------
11 -'git-rev-parse' [ --option ] <args>...
11 +'git rev-parse' [ --option ] <args>...
12
13 DESCRIPTION
14 -----------
@@ -296,7 +296,7 @@ reachable from `r1` from the set of commits reachable from
296
297 A similar notation "`r1\...r2`" is called symmetric difference
298 of `r1` and `r2` and is defined as
299 -"`r1 r2 --not $(git-merge-base --all r1 r2)`".
299 +"`r1 r2 --not $(git merge-base --all r1 r2)`".
300 It is the set of commits that are reachable from either one of
301 `r1` or `r2` but not from both.
302
@@ -384,7 +384,7 @@ bar= some cool option --bar with an argument
384 An option group Header
385 C? option C with an optional argument"
386
387 -eval `echo "$OPTS_SPEC" | git-rev-parse --parseopt -- "$@" || echo exit $?`
387 +eval `echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?`
388 ------------
389
390 EXAMPLES
Documentation/git-revert.txt
+1 -1
@@ -7,7 +7,7 @@ git-revert - Revert an existing commit
7
8 SYNOPSIS
9 --------
10 -'git-revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>
10 +'git revert' [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>
11
12 DESCRIPTION
13 -----------
Documentation/git-rm.txt
+4 -4
@@ -7,12 +7,12 @@ git-rm - Remove files from the working tree and from the index
7
8 SYNOPSIS
9 --------
10 -'git-rm' [-f] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>...
10 +'git rm' [-f] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>...
11
12 DESCRIPTION
13 -----------
14 Remove files from the index, or from the working tree and the index.
15 -`git rm` will not remove a file from just your working directory.
15 +`git-rm` will not remove a file from just your working directory.
16 (There is no option to remove a file only from the work tree
17 and yet keep it in the index; use `/bin/rm` if you want to do that.)
18 The files being removed have to be identical to the tip of the branch,
@@ -82,7 +82,7 @@ also remove all of directory `d2`.
82
83 EXAMPLES
84 --------
85 -git-rm Documentation/\\*.txt::
85 +git rm Documentation/\\*.txt::
86 Removes all `\*.txt` files from the index that are under the
87 `Documentation` directory and any of its subdirectories.
88 +
@@ -90,7 +90,7 @@ Note that the asterisk `\*` is quoted from the shell in this
90 example; this lets git, and not the shell, expand the pathnames
91 of files and subdirectories under the `Documentation/` directory.
92
93 -git-rm -f git-*.sh::
93 +git rm -f git-*.sh::
94 Because this example lets the shell expand the asterisk
95 (i.e. you are listing the files explicitly), it
96 does not remove `subdir/git-foo.sh`.
Documentation/git-send-email.txt
+1 -1
@@ -8,7 +8,7 @@ git-send-email - Send a collection of patches as emails
8
9 SYNOPSIS
10 --------
11 -'git-send-email' [options] <file|directory> [... file|directory]
11 +'git send-email' [options] <file|directory> [... file|directory]
12
13
14
Documentation/git-send-pack.txt
+1 -1
@@ -8,7 +8,7 @@ git-send-pack - Push objects over git protocol to another repository
8
9 SYNOPSIS
10 --------
11 -'git-send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
11 +'git send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
12
13 DESCRIPTION
14 -----------
Documentation/git-shortlog.txt
+3 -3
@@ -8,12 +8,12 @@ git-shortlog - Summarize 'git log' output
8 SYNOPSIS
9 --------
10 [verse]
11 -git-log --pretty=short | 'git-shortlog' [-h] [-n] [-s] [-e] [-w]
12 -git-shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] [<committish>...]
11 +git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w]
12 +git shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] [<committish>...]
13
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.
19
Documentation/git-show-branch.txt
+2 -2
@@ -8,10 +8,10 @@ git-show-branch - Show branches and their commits
8 SYNOPSIS
9 --------
10 [verse]
11 -'git-show-branch' [--all] [--remotes] [--topo-order] [--current]
11 +'git show-branch' [--all] [--remotes] [--topo-order] [--current]
12 [--more=<n> | --list | --independent | --merge-base]
13 [--no-name | --sha1-name] [--topics] [<rev> | <glob>]...
14 -'git-show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]
14 +'git show-branch' (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]
15
16 DESCRIPTION
17 -----------
Documentation/git-show-index.txt
+1 -1
@@ -8,7 +8,7 @@ git-show-index - Show packed archive index
8
9 SYNOPSIS
10 --------
11 -'git-show-index' < idx-file
11 +'git show-index' < idx-file
12
13
14 DESCRIPTION
Documentation/git-show-ref.txt
+3 -3
@@ -8,9 +8,9 @@ git-show-ref - List references in a local repository
8 SYNOPSIS
9 --------
10 [verse]
11 -'git-show-ref' [-q|--quiet] [--verify] [-h|--head] [-d|--dereference]
11 +'git show-ref' [-q|--quiet] [--verify] [-h|--head] [-d|--dereference]
12 [-s|--hash] [--abbrev] [--tags] [--heads] [--] <pattern>...
13 -'git-show-ref' --exclude-existing[=pattern]
13 +'git show-ref' --exclude-existing[=pattern]
14
15 DESCRIPTION
16 -----------
@@ -144,7 +144,7 @@ For scripting, you can ask it to be quiet with the "--quiet" flag, which
144 allows you to do things like
145
146 -----------------------------------------------------------------------------
147 - git-show-ref --quiet --verify -- "refs/heads/$headname" ||
147 + git show-ref --quiet --verify -- "refs/heads/$headname" ||
148 echo "$headname is not a valid branch"
149 -----------------------------------------------------------------------------
150
Documentation/git-show.txt
+1 -1
@@ -8,7 +8,7 @@ git-show - Show various types of objects
8
9 SYNOPSIS
10 --------
11 -'git-show' [options] <object>...
11 +'git show' [options] <object>...
12
13 DESCRIPTION
14 -----------
Documentation/git-stash.txt
+6 -6
@@ -8,13 +8,13 @@ git-stash - Stash the changes in a dirty working directory away
8 SYNOPSIS
9 --------
10 [verse]
11 -'git-stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
12 -'git-stash' [save [<message>]]
11 +'git stash' (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
12 +'git stash' [save [<message>]]
13
14 DESCRIPTION
15 -----------
16
17 -Use 'git-stash' when you want to record the current state of the
17 +Use 'git stash' when you want to record the current state of the
18 working directory and the index, but want to go back to a clean
19 working directory. The command saves your local modifications away
20 and reverts the working directory to match the `HEAD` commit.
@@ -22,7 +22,7 @@ and reverts the working directory to match the `HEAD` commit.
22 The modifications stashed away by this command can be listed with
23 `git-stash list`, inspected with `git-stash show`, and restored
24 (potentially on top of a different commit) with `git-stash apply`.
25 -Calling git-stash without any arguments is equivalent to `git-stash
25 +Calling git stash without any arguments is equivalent to `git stash
26 save`. A stash is by default listed as "WIP on 'branchname' ...", but
27 you can give a more descriptive message on the command line when
28 you create one.
@@ -38,7 +38,7 @@ OPTIONS
38
39 save [<message>]::
40
41 - Save your local modifications to a new 'stash', and run `git-reset
41 + Save your local modifications to a new 'stash', and run `git reset
42 --hard` to revert them. This is the default action when no
43 subcommand is given. The <message> part is optional and gives
44 the description along with the stashed state.
@@ -64,7 +64,7 @@ show [<stash>]::
64 Show the changes recorded in the stash as a diff between the
65 stashed state and its original parent. When no `<stash>` is given,
66 shows the latest one. By default, the command shows the diffstat, but
67 - it will accept any format known to `git-diff` (e.g., `git-stash show
67 + it will accept any format known to `git-diff` (e.g., `git stash show
68 -p stash@\{1}` to view the second most recent stash in patch form).
69
70 apply [--index] [<stash>]::
Documentation/git-status.txt
+3 -3
@@ -8,7 +8,7 @@ git-status - Show the working tree status
8
9 SYNOPSIS
10 --------
11 -'git-status' <options>...
11 +'git status' <options>...
12
13 DESCRIPTION
14 -----------
@@ -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`.
22
23 The command takes the same set of options as `git-commit`; it
@@ -26,7 +26,7 @@ shows what would be committed if the same options are given to
26
27 If there is no path that is different between the index file and
28 the current HEAD commit (i.e., there is nothing to commit by running
29 -`git-commit`), the command exits with non-zero status.
29 +`git commit`), the command exits with non-zero status.
30
31
32 OUTPUT
Documentation/git-stripspace.txt
+1 -1
@@ -8,7 +8,7 @@ git-stripspace - Filter out empty lines
8
9 SYNOPSIS
10 --------
11 -'git-stripspace' [-s | --strip-comments] < <stream>
11 +'git stripspace' [-s | --strip-comments] < <stream>
12
13 DESCRIPTION
14 -----------
Documentation/git-submodule.txt
+5 -5
@@ -9,11 +9,11 @@ git-submodule - Initialize, update or inspect submodules
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-submodule' [--quiet] add [-b branch] [--] <repository> [<path>]
13 -'git-submodule' [--quiet] status [--cached] [--] [<path>...]
14 -'git-submodule' [--quiet] init [--] [<path>...]
15 -'git-submodule' [--quiet] update [--init] [--] [<path>...]
16 -'git-submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]
12 +'git submodule' [--quiet] add [-b branch] [--] <repository> [<path>]
13 +'git submodule' [--quiet] status [--cached] [--] [<path>...]
14 +'git submodule' [--quiet] init [--] [<path>...]
15 +'git submodule' [--quiet] update [--init] [--] [<path>...]
16 +'git submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]
17
18
19 COMMANDS
Documentation/git-svn.txt
+17 -17
@@ -7,7 +7,7 @@ git-svn - Bidirectional operation between a single Subversion branch and git
7
8 SYNOPSIS
9 --------
10 -'git-svn' <command> [options] [arguments]
10 +'git svn' <command> [options] [arguments]
11
12 DESCRIPTION
13 -----------
@@ -173,7 +173,7 @@ NOTE: SVN itself only stores times in UTC and nothing else. The regular svn
173 client converts the UTC time to the local time (or based on the TZ=
174 environment). This command has the same behaviour.
175 +
176 -Any other arguments are passed directly to `git log'
176 +Any other arguments are passed directly to `git-log'
177
178 'blame'::
179 Show what revision and author last modified each line of a file. The
@@ -184,7 +184,7 @@ Any other arguments are passed directly to `git log'
184 arguments are passed directly to git-blame.
185 +
186 --git-format;;
187 - Produce output in the same format as `git blame', but with
187 + Produce output in the same format as `git-blame', but with
188 SVN revision numbers instead of git commit hashes. In this mode,
189 changes that haven't been committed to SVN (including local
190 working-copy edits) are shown as revision 0.
@@ -466,7 +466,7 @@ Tracking and contributing to the trunk of a Subversion-managed project:
466
467 ------------------------------------------------------------------------
468 # Clone a repo (like git clone):
469 - git-svn clone http://svn.foo.org/project/trunk
469 + git svn clone http://svn.foo.org/project/trunk
470 # Enter the newly cloned directory:
471 cd trunk
472 # You should be on master branch, double-check with git-branch
@@ -475,12 +475,12 @@ Tracking and contributing to the trunk of a Subversion-managed project:
475 git commit ...
476 # Something is committed to SVN, rebase your local changes against the
477 # latest changes in SVN:
478 - git-svn rebase
478 + git svn rebase
479 # Now commit your changes (that were committed previously using git) to SVN,
480 # as well as automatically updating your working HEAD:
481 - git-svn dcommit
481 + git svn dcommit
482 # Append svn:ignore settings to the default git exclude file:
483 - git-svn show-ignore >> .git/info/exclude
483 + git svn show-ignore >> .git/info/exclude
484 ------------------------------------------------------------------------
485
486 Tracking and contributing to an entire Subversion-managed project
@@ -488,7 +488,7 @@ Tracking and contributing to an entire Subversion-managed project
488
489 ------------------------------------------------------------------------
490 # Clone a repo (like git clone):
491 - git-svn clone http://svn.foo.org/project -T trunk -b branches -t tags
491 + git svn clone http://svn.foo.org/project -T trunk -b branches -t tags
492 # View all branches and tags you have cloned:
493 git branch -r
494 # Reset your master to trunk (or any other branch, replacing 'trunk'
@@ -503,22 +503,22 @@ The initial 'git-svn clone' can be quite time-consuming
503 people (or one person with multiple machines) want to use
504 git-svn to interact with the same Subversion repository, you can
505 do the initial 'git-svn clone' to a repository on a server and
506 -have each person clone that repository with 'git clone':
506 +have each person clone that repository with 'git-clone':
507
508 ------------------------------------------------------------------------
509 # Do the initial import on a server
510 - ssh server "cd /pub && git-svn clone http://svn.foo.org/project
510 + ssh server "cd /pub && git svn clone http://svn.foo.org/project
511 # Clone locally - make sure the refs/remotes/ space matches the server
512 mkdir project
513 cd project
514 - git-init
514 + git init
515 git remote add origin server:/pub/project
516 git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
517 git fetch
518 # Initialize git-svn locally (be sure to use the same URL and -T/-b/-t options as were used on server)
519 - git-svn init http://svn.foo.org/project
519 + git svn init http://svn.foo.org/project
520 # Pull the latest changes from Subversion
521 - git-svn rebase
521 + git svn rebase
522 ------------------------------------------------------------------------
523
524 REBASE VS. PULL/MERGE
@@ -526,12 +526,12 @@ REBASE VS. PULL/MERGE
526
527 Originally, git-svn recommended that the remotes/git-svn branch be
528 pulled or merged from. This is because the author favored
529 -'git-svn set-tree B' to commit a single head rather than the
530 -'git-svn set-tree A..B' notation to commit multiple commits.
529 +'git svn set-tree B' to commit a single head rather than the
530 +'git svn set-tree A..B' notation to commit multiple commits.
531
532 -If you use 'git-svn set-tree A..B' to commit several diffs and you do
532 +If you use 'git svn set-tree A..B' to commit several diffs and you do
533 not have the latest remotes/git-svn merged into my-branch, you should
534 -use 'git-svn rebase' to update your work branch instead of 'git pull' or
534 +use 'git svn rebase' to update your work branch instead of 'git pull' or
535 'git merge'. 'pull/merge' can cause non-linear history to be flattened
536 when committing into SVN, which can lead to merge commits reversing
537 previous commits in SVN.
Documentation/git-symbolic-ref.txt
+1 -1
@@ -7,7 +7,7 @@ git-symbolic-ref - Read and modify symbolic refs
7
8 SYNOPSIS
9 --------
10 -'git-symbolic-ref' [-q] [-m <reason>] <name> [<ref>]
10 +'git symbolic-ref' [-q] [-m <reason>] <name> [<ref>]
11
12 DESCRIPTION
13 -----------
Documentation/git-tag.txt
+7 -7
@@ -9,10 +9,10 @@ git-tag - Create, list, delete or verify a tag object signed with GPG
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <name> [<head>]
13 -'git-tag' -d <name>...
14 -'git-tag' [-n[<num>]] -l [<pattern>]
15 -'git-tag' -v <name>...
12 +'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <name> [<head>]
13 +'git tag' -d <name>...
14 +'git tag' [-n[<num>]] -l [<pattern>]
15 +'git tag' -v <name>...
16
17 DESCRIPTION
18 -----------
@@ -118,12 +118,12 @@ and be done with it.
118
119 . The insane thing.
120 You really want to call the new version "X" too, 'even though'
121 -others have already seen the old one. So just use "git tag -f"
121 +others have already seen the old one. So just use "git-tag -f"
122 again, as if you hadn't already published the old one.
123
124 However, Git does *not* (and it should not) change tags behind
125 users back. So if somebody already got the old tag, doing a
126 -"git pull" on your tree shouldn't just make them overwrite the old
126 +"git-pull" on your tree shouldn't just make them overwrite the old
127 one.
128
129 If somebody got a release tag from you, you cannot just change
@@ -177,7 +177,7 @@ private anchor point tags from the other person.
177
178 You would notice "please pull" messages on the mailing list says
179 repo URL and branch name alone. This is designed to be easily
180 -cut&pasted to "git fetch" command line:
180 +cut&pasted to "git-fetch" command line:
181
182 ------------
183 Linus, please pull from
Documentation/git-tar-tree.txt
+1 -1
@@ -8,7 +8,7 @@ git-tar-tree - Create a tar archive of the files in the named tree object
8
9 SYNOPSIS
10 --------
11 -'git-tar-tree' [--remote=<repo>] <tree-ish> [ <base> ]
11 +'git tar-tree' [--remote=<repo>] <tree-ish> [ <base> ]
12
13 DESCRIPTION
14 -----------
Documentation/git-unpack-file.txt
+1 -1
@@ -9,7 +9,7 @@ git-unpack-file - Creates a temporary file with a blob's contents
9
10 SYNOPSIS
11 --------
12 -'git-unpack-file' <blob>
12 +'git unpack-file' <blob>
13
14 DESCRIPTION
15 -----------
Documentation/git-unpack-objects.txt
+1 -1
@@ -8,7 +8,7 @@ git-unpack-objects - Unpack objects from a packed archive
8
9 SYNOPSIS
10 --------
11 -'git-unpack-objects' [-n] [-q] [-r] [--strict] <pack-file
11 +'git unpack-objects' [-n] [-q] [-r] [--strict] <pack-file
12
13
14 DESCRIPTION
Documentation/git-update-index.txt
+6 -6
@@ -9,7 +9,7 @@ git-update-index - Register file contents in the working tree to the index
9 SYNOPSIS
10 --------
11 [verse]
12 -'git-update-index'
12 +'git update-index'
13 [--add] [--remove | --force-remove] [--replace]
14 [--refresh] [-q] [--unmerged] [--ignore-missing]
15 [--cacheinfo <mode> <object> <file>]\*
@@ -157,7 +157,7 @@ merging.
157 To pretend you have a file with mode and sha1 at path, say:
158
159 ----------------
160 -$ git-update-index --cacheinfo mode sha1 path
160 +$ git update-index --cacheinfo mode sha1 path
161 ----------------
162
163 '--info-only' is used to register files without placing them in the object
@@ -247,13 +247,13 @@ In order to set "assume unchanged" bit, use `--assume-unchanged`
247 option. To unset, use `--no-assume-unchanged`.
248
249 The command looks at `core.ignorestat` configuration variable. When
250 -this is true, paths updated with `git-update-index paths...` and
250 +this is true, paths updated with `git update-index paths...` and
251 paths updated with other git commands that update both index and
252 working tree (e.g. `git-apply --index`, `git-checkout-index -u`,
253 and `git-read-tree -u`) are automatically marked as "assume
254 unchanged". Note that "assume unchanged" bit is *not* set if
255 -`git-update-index --refresh` finds the working tree file matches
256 -the index (use `git-update-index --really-refresh` if you want
255 +`git update-index --refresh` finds the working tree file matches
256 +the index (use `git update-index --really-refresh` if you want
257 to mark them as "assume unchanged").
258
259
@@ -262,7 +262,7 @@ Examples
262 To update and refresh only the files already checked out:
263
264 ----------------
265 -$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
265 +$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
266 ----------------
267
268 On an inefficient filesystem with `core.ignorestat` set::
Documentation/git-update-ref.txt
+5 -5
@@ -7,18 +7,18 @@ git-update-ref - Update the object name stored in a ref safely
7
8 SYNOPSIS
9 --------
10 -'git-update-ref' [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] <ref> <newvalue> [<oldvalue>])
10 +'git update-ref' [-m <reason>] (-d <ref> [<oldvalue>] | [--no-deref] <ref> <newvalue> [<oldvalue>])
11
12 DESCRIPTION
13 -----------
14 Given two arguments, stores the <newvalue> in the <ref>, possibly
15 -dereferencing the symbolic refs. E.g. `git-update-ref HEAD
15 +dereferencing the symbolic refs. E.g. `git update-ref HEAD
16 <newvalue>` updates the current branch head to the new object.
17
18 Given three arguments, stores the <newvalue> in the <ref>,
19 possibly dereferencing the symbolic refs, after verifying that
20 the current value of the <ref> matches <oldvalue>.
21 -E.g. `git-update-ref refs/heads/master <newvalue> <oldvalue>`
21 +E.g. `git update-ref refs/heads/master <newvalue> <oldvalue>`
22 updates the master branch head to <newvalue> only if its current
23 value is <oldvalue>. You can specify 40 "0" or an empty string
24 as <oldvalue> to make sure that the ref you are creating does
@@ -41,7 +41,7 @@ the result of following the symbolic pointers.
41
42 In general, using
43
44 - git-update-ref HEAD "$head"
44 + git update-ref HEAD "$head"
45
46 should be a _lot_ safer than doing
47
@@ -61,7 +61,7 @@ still contains <oldvalue>.
61 Logging Updates
62 ---------------
63 If config parameter "core.logAllRefUpdates" is true or the file
64 -"$GIT_DIR/logs/<ref>" exists then `git-update-ref` will append
64 +"$GIT_DIR/logs/<ref>" exists then `git update-ref` will append
65 a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all
66 symbolic refs before creating the log name) describing the change
67 in ref value. Log lines are formatted as:
Documentation/git-update-server-info.txt
+1 -1
@@ -8,7 +8,7 @@ git-update-server-info - Update auxiliary info file to help dumb servers
8
9 SYNOPSIS
10 --------
11 -'git-update-server-info' [--force]
11 +'git update-server-info' [--force]
12
13 DESCRIPTION
14 -----------
Documentation/git-upload-archive.txt
+1 -1
@@ -8,7 +8,7 @@ git-upload-archive - Send archive back to git-archive
8
9 SYNOPSIS
10 --------
11 -'git-upload-archive' <directory>
11 +'git upload-archive' <directory>
12
13 DESCRIPTION
14 -----------
Documentation/git-upload-pack.txt
+1 -1
@@ -8,7 +8,7 @@ git-upload-pack - Send objects packed back to git-fetch-pack
8
9 SYNOPSIS
10 --------
11 -'git-upload-pack' [--strict] [--timeout=<n>] <directory>
11 +'git upload-pack' [--strict] [--timeout=<n>] <directory>
12
13 DESCRIPTION
14 -----------
Documentation/git-var.txt
+2 -2
@@ -8,7 +8,7 @@ git-var - Show a git logical variable
8
9 SYNOPSIS
10 --------
11 -'git-var' [ -l | <variable> ]
11 +'git var' [ -l | <variable> ]
12
13 DESCRIPTION
14 -----------
@@ -24,7 +24,7 @@ OPTIONS
24
25 EXAMPLE
26 --------
27 - $ git-var GIT_AUTHOR_IDENT
27 + $ git var GIT_AUTHOR_IDENT
28 Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600
29
30
Documentation/git-verify-pack.txt
+1 -1
@@ -8,7 +8,7 @@ git-verify-pack - Validate packed git archive files
8
9 SYNOPSIS
10 --------
11 -'git-verify-pack' [-v] [--] <pack>.idx ...
11 +'git verify-pack' [-v] [--] <pack>.idx ...
12
13
14 DESCRIPTION
Documentation/git-verify-tag.txt
+1 -1
@@ -7,7 +7,7 @@ git-verify-tag - Check the GPG signature of tags
7
8 SYNOPSIS
9 --------
10 -'git-verify-tag' <tag>...
10 +'git verify-tag' <tag>...
11
12 DESCRIPTION
13 -----------
Documentation/git-web--browse.txt
+3 -3
@@ -7,7 +7,7 @@ git-web--browse - git helper script to launch a web browser
7
8 SYNOPSIS
9 --------
10 -'git-web--browse' [OPTIONS] URL/FILE ...
10 +'git web--browse' [OPTIONS] URL/FILE ...
11
12 DESCRIPTION
13 -----------
@@ -70,7 +70,7 @@ browser.<tool>.cmd
70 When the browser, specified by options or configuration variables, is
71 not among the supported ones, then the corresponding
72 'browser.<tool>.cmd' configuration variable will be looked up. If this
73 -variable exists then "git web--browse" will treat the specified tool
73 +variable exists then "git-web--browse" will treat the specified tool
74 as a custom command and will use a shell eval to run the command with
75 the URLs passed as arguments.
76
@@ -96,7 +96,7 @@ the following:
96 cmd = A_PATH_TO/konqueror
97 ------------------------------------------------
98
99 -Note about git config --global
99 +Note about git-config --global
100 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
101
102 Note that these configuration variables should probably be set using
Documentation/git-whatchanged.txt
+3 -3
@@ -8,7 +8,7 @@ git-whatchanged - Show logs with difference each commit introduces
8
9 SYNOPSIS
10 --------
11 -'git-whatchanged' <option>...
11 +'git whatchanged' <option>...
12
13 DESCRIPTION
14 -----------
@@ -52,12 +52,12 @@ include::pretty-formats.txt[]
52
53 Examples
54 --------
55 -git-whatchanged -p v2.6.12.. include/scsi drivers/scsi::
55 +git whatchanged -p v2.6.12.. include/scsi drivers/scsi::
56
57 Show as patches the commits since version 'v2.6.12' that changed
58 any file in the include/scsi or drivers/scsi subdirectories
59
60 -git-whatchanged --since="2 weeks ago" \-- gitk::
60 +git whatchanged --since="2 weeks ago" \-- gitk::
61
62 Show the changes during the last two weeks to the file 'gitk'.
63 The "--" is necessary to avoid confusion with the *branch* named
Documentation/git-write-tree.txt
+1 -1
@@ -8,7 +8,7 @@ git-write-tree - Create a tree object from the current index
8
9 SYNOPSIS
10 --------
11 -'git-write-tree' [--missing-ok] [--prefix=<prefix>/]
11 +'git write-tree' [--missing-ok] [--prefix=<prefix>/]
12
13 DESCRIPTION
14 -----------
Documentation/gitattributes.txt
+7 -7
@@ -87,9 +87,9 @@ Checking-out and checking-in
87
88 These attributes affect how the contents stored in the
89 repository are copied to the working tree files when commands
90 -such as `git checkout` and `git merge` run. They also affect how
90 +such as `git-checkout` and `git-merge` run. They also affect how
91 git stores the contents you prepare in the working tree in the
92 -repository upon `git add` and `git commit`.
92 +repository upon `git-add` and `git-commit`.
93
94 `crlf`
95 ^^^^^^
@@ -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
@@ -214,7 +214,7 @@ with `crlf`, and then `ident` and fed to `filter`.
214 Generating diff text
215 ~~~~~~~~~~~~~~~~~~~~
216
217 -The attribute `diff` affects if `git diff` generates textual
217 +The attribute `diff` affects if `git-diff` generates textual
218 patch for the path or just says `Binary files differ`. It also
219 can affect what line is shown on the hunk header `@@ -k,l +n,m @@`
220 line.
Documentation/gitcore-tutorial.txt
+51 -51
@@ -49,7 +49,7 @@ subdirectory, and initialize the git infrastructure with `git-init`:
49 ------------------------------------------------
50 $ mkdir git-tutorial
51 $ cd git-tutorial
52 -$ git-init
52 +$ git init
53 ------------------------------------------------
54
55 to which git will reply
@@ -149,7 +149,7 @@ adding a new entry with the `\--add` flag (or removing an entry with the
149 So to populate the index with the two files you just created, you can do
150
151 ------------------------------------------------
152 -$ git-update-index --add hello example
152 +$ git update-index --add hello example
153 ------------------------------------------------
154
155 and you have now told git to track those two files.
@@ -177,7 +177,7 @@ 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
180 +$ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
181 ----------------
182
183 where the `-t` tells `git-cat-file` to tell you what the "type" of the
@@ -185,7 +185,7 @@ 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
187 ----------------
188 -$ git-cat-file "blob" 557db03
188 +$ git cat-file "blob" 557db03
189 ----------------
190
191 which will print out "Hello World". The object `557db03` is nothing
@@ -231,7 +231,7 @@ git what has changed in the tree compared to your old index, using the
231 `git-diff-files` command:
232
233 ------------
234 -$ git-diff-files
234 +$ git diff-files
235 ------------
236
237 Oops. That wasn't very readable. It just spit out its own internal
@@ -243,7 +243,7 @@ To make it readable, we can tell git-diff-files to output the
243 differences as a patch, using the `-p` flag:
244
245 ------------
246 -$ git-diff-files -p
246 +$ git diff-files -p
247 diff --git a/hello b/hello
248 index 557db03..263414f 100644
249 --- a/hello
@@ -259,7 +259,7 @@ 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
262 -A common shorthand for `git-diff-files -p` is to just write `git
262 +A common shorthand for `git diff-files -p` is to just write `git
263 diff`, which will do the same thing.
264
265 ------------
@@ -284,14 +284,14 @@ 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`.
287 -There are no options or other input: git-write-tree will take the
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
290 filenames with their contents (and their permissions), and we're
291 creating the equivalent of a git "directory" object:
292
293 ------------------------------------------------
294 -$ git-write-tree
294 +$ git write-tree
295 ------------------------------------------------
296
297 and this will just output the name of the resulting tree, in this case
@@ -302,9 +302,9 @@ and this will just output the name of the resulting tree, in this case
302 ----------------
303
304 which is another incomprehensible object name. Again, if you want to,
305 -you can use `git-cat-file -t 8988d\...` to see that this time the object
305 +you can use `git cat-file -t 8988d\...` to see that this time the object
306 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
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
@@ -327,9 +327,9 @@ that's exactly what `git-commit-tree` spits out, we can do this
327 all with a sequence of simple shell commands:
328
329 ------------------------------------------------
330 -$ tree=$(git-write-tree)
331 -$ commit=$(echo 'Initial commit' | git-commit-tree $tree)
332 -$ git-update-ref HEAD $commit
330 +$ tree=$(git write-tree)
331 +$ commit=$(echo 'Initial commit' | git commit-tree $tree)
332 +$ git update-ref HEAD $commit
333 ------------------------------------------------
334
335 In this case this creates a totally new commit that is not related to
@@ -356,7 +356,7 @@ that on purpose, to show the difference between the index state, and the
356 state in the working tree, and how they don't have to match, even
357 when we commit things.
358
359 -As before, if we do `git-diff-files -p` in our git-tutorial project,
359 +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:
@@ -372,7 +372,7 @@ didn't have anything to diff against.
372 But now we can do
373
374 ----------------
375 -$ git-diff-index -p HEAD
375 +$ git diff-index -p HEAD
376 ----------------
377
378 (where `-p` has the same meaning as it did in `git-diff-files`), and it
@@ -394,7 +394,7 @@ 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
397 -file to HEAD, doing `git-diff-index \--cached -p HEAD` should thus return
397 +file to HEAD, doing `git diff-index \--cached -p HEAD` should thus return
398 an empty set of differences, and that's exactly what it does.
399
400 [NOTE]
@@ -422,15 +422,15 @@ work through the index file, so the first thing we need to do is to
422 update the index cache:
423
424 ------------------------------------------------
425 -$ git-update-index hello
425 +$ git update-index hello
426 ------------------------------------------------
427
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
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
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`
436 flag or not, since now the index is coherent with the working tree.
@@ -477,7 +477,7 @@ of that commit itself, and show the difference directly. Thus, to get
477 the same diff that we've already seen several times, we can now do
478
479 ----------------
480 -$ git-diff-tree -p HEAD
480 +$ git diff-tree -p HEAD
481 ----------------
482
483 (again, `-p` means to show the difference as a human-readable patch),
@@ -542,7 +542,7 @@ with the associated patches use the more complex (and much more
542 powerful)
543
544 ----------------
545 -$ git-whatchanged -p
545 +$ git whatchanged -p
546 ----------------
547
548 and you will see exactly what has changed in the repository over its
@@ -653,7 +653,7 @@ information for the files involved) will likely need to be refreshed.
653 So after you do a `cp -a` to create a new copy, you'll want to do
654 +
655 ----------------
656 -$ git-update-index --refresh
656 +$ git update-index --refresh
657 ----------------
658 +
659 in the new repository to make sure that the index file is up-to-date.
@@ -669,15 +669,15 @@ 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
670
671 ----------------
672 -$ git-read-tree --reset HEAD
673 -$ git-update-index --refresh
672 +$ git read-tree --reset HEAD
673 +$ 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`
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
680 +working tree, `git update-index --refresh` notices them and
681 tells you they need to be updated.
682
683 The above can also be written as simply
@@ -690,7 +690,7 @@ 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
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
@@ -713,7 +713,7 @@ $ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git
713 followed by
714
715 ----------------
716 -$ git-read-tree HEAD
716 +$ git read-tree HEAD
717 ----------------
718
719 to populate the index. However, now you have populated the index, and
@@ -722,7 +722,7 @@ actually have any of the working tree files to work on. To get
722 those, you'd check them out with
723
724 ----------------
725 -$ git-checkout-index -u -a
725 +$ git checkout-index -u -a
726 ----------------
727
728 where the `-u` flag means that you want the checkout to keep the index
@@ -839,7 +839,7 @@ $ git commit -m "Some work." -i hello
839 ------------------------------------------------
840
841 Here, we just added another line to `hello`, and we used a shorthand for
842 -doing both `git-update-index hello` and `git commit` by just giving the
842 +doing both `git update-index hello` and `git commit` by just giving the
843 filename directly to `git commit`, with an `-i` flag (it tells
844 git to 'include' that file in addition to what you have done to
845 the index file so far when making the commit). The `-m` flag is to give the
@@ -938,7 +938,7 @@ Another useful tool, especially if you do not always work in X-Window
938 environment, is `git show-branch`.
939
940 ------------------------------------------------
941 -$ git-show-branch --topo-order --more=1 master mybranch
941 +$ git show-branch --topo-order --more=1 master mybranch
942 * [master] Merge work in mybranch
943 ! [mybranch] Some work.
944 --
@@ -981,7 +981,7 @@ merge commit visible in this case.
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
@@ -1198,7 +1198,7 @@ algorithm. First, it finds the common ancestor between them.
1198 The command it uses is `git-merge-base`:
1199
1200 ------------
1201 -$ mb=$(git-merge-base HEAD mybranch)
1201 +$ mb=$(git merge-base HEAD mybranch)
1202 ------------
1203
1204 The command writes the commit object name of the common ancestor
@@ -1208,7 +1208,7 @@ ancestor commit is the "New day." commit in this case. You can
1208 tell it by:
1209
1210 ------------
1211 -$ git-name-rev $mb
1211 +$ git name-rev $mb
1212 my-first-tag
1213 ------------
1214
@@ -1216,7 +1216,7 @@ After finding out a common ancestor commit, the second step is
1216 this:
1217
1218 ------------
1219 -$ git-read-tree -m -u $mb HEAD mybranch
1219 +$ git read-tree -m -u $mb HEAD mybranch
1220 ------------
1221
1222 This is the same `git-read-tree` command we have already seen,
@@ -1235,7 +1235,7 @@ trees are left in non-zero stages. At this point, you can
1235 inspect the index file with this command:
1236
1237 ------------
1238 -$ git-ls-files --stage
1238 +$ git ls-files --stage
1239 100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example
1240 100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
1241 100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
@@ -1252,7 +1252,7 @@ stages.
1252 To look at only non-zero stages, use `\--unmerged` flag:
1253
1254 ------------
1255 -$ git-ls-files --unmerged
1255 +$ git ls-files --unmerged
1256 100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
1257 100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
1258 100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
@@ -1264,7 +1264,7 @@ file, using 3-way merge. This is done by giving
1264 `git-merge-index` command:
1265
1266 ------------
1267 -$ git-merge-index git-merge-one-file hello
1267 +$ git merge-index git-merge-one-file hello
1268 Auto-merging hello.
1269 merge: warning: conflicts during merge
1270 ERROR: Merge conflict in hello.
@@ -1282,7 +1282,7 @@ the working tree.. This can be seen if you run `ls-files
1282 --stage` again at this point:
1283
1284 ------------
1285 -$ git-ls-files --stage
1285 +$ git ls-files --stage
1286 100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example
1287 100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
1288 100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
@@ -1290,9 +1290,9 @@ $ git-ls-files --stage
1290 ------------
1291
1292 This is the state of the index file and the working file after
1293 -`git merge` returns control back to you, leaving the conflicting
1293 +`git-merge` returns control back to you, leaving the conflicting
1294 merge for you to resolve. Notice that the path `hello` is still
1295 -unmerged, and what you see with `git diff` at this point is
1295 +unmerged, and what you see with `git-diff` at this point is
1296 differences since stage 2 (i.e. your version).
1297
1298
@@ -1329,7 +1329,7 @@ into it later. Obviously, this repository creation needs to be
1329 done only once.
1330
1331 [NOTE]
1332 -`git push` uses a pair of programs,
1332 +`git-push` uses a pair of programs,
1333 `git-send-pack` on your local machine, and `git-receive-pack`
1334 on the remote machine. The communication between the two over
1335 the network internally uses an SSH connection.
@@ -1349,7 +1349,7 @@ Then, make that directory into a git repository by running
1349 `.git`, we do things slightly differently:
1350
1351 ------------
1352 -$ GIT_DIR=my-git.git git-init
1352 +$ GIT_DIR=my-git.git git init
1353 ------------
1354
1355 Make sure this directory is available for others you want your
@@ -1368,7 +1368,7 @@ your login shell is `bash`, only `.bashrc` is read and not
1368 If you plan to publish this repository to be accessed over http,
1369 you should do `chmod +x my-git.git/hooks/post-update` at this
1370 point. This makes sure that every time you push into this
1371 -repository, `git-update-server-info` is run.
1371 +repository, `git update-server-info` is run.
1372
1373 Your "public repository" is now ready to accept your changes.
1374 Come back to the machine you have your private repository. From
@@ -1495,9 +1495,9 @@ keeps the necessary files up-to-date.
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
Documentation/gitcvs-migration.txt
+4 -4
@@ -47,7 +47,7 @@ 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 ================================
@@ -60,12 +60,12 @@ $ git push origin master
60 ------------------------------------------------
61
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.
66
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:
71
Documentation/gitdiffcore.txt
+1 -1
@@ -84,7 +84,7 @@ of filepairs included:
84 :100644 100644 bcd1234... 0123456... M junkfile
85 ------------------------------------------------
86
87 -but the command invocation was "git-diff-files myfile", then the
87 +but the command invocation was "git diff-files myfile", then the
88 junkfile entry would be removed from the list because only "myfile"
89 is under consideration.
90
Documentation/githooks.txt
+5 -5
@@ -147,7 +147,7 @@ properties.
147 post-merge
148 -----------
149
150 -This hook is invoked by `git-merge`, which happens when a `git pull`
150 +This hook is invoked by `git-merge`, which happens when a `git-pull`
151 is done on a local repository. The hook takes a single parameter, a status
152 flag specifying whether or not the merge being done was a squash merge.
153 This hook cannot affect the outcome of `git-merge` and is not executed,
@@ -163,7 +163,7 @@ pre-receive
163 -----------
164
165 This hook is invoked by `git-receive-pack` on the remote repository,
166 -which happens when a `git push` is done on a local repository.
166 +which happens when a `git-push` is done on a local repository.
167 Just before starting to update refs on the remote repository, the
168 pre-receive hook is invoked. Its exit status determines the success
169 or failure of the update.
@@ -192,7 +192,7 @@ update
192 ------
193
194 This hook is invoked by `git-receive-pack` on the remote repository,
195 -which happens when a `git push` is done on a local repository.
195 +which happens when a `git-push` is done on a local repository.
196 Just before updating the ref on the remote repository, the update hook
197 is invoked. Its exit status determines the success or failure of
198 the ref update.
@@ -235,7 +235,7 @@ post-receive
235 ------------
236
237 This hook is invoked by `git-receive-pack` on the remote repository,
238 -which happens when a `git push` is done on a local repository.
238 +which happens when a `git-push` is done on a local repository.
239 It executes on the remote repository once after all the refs have
240 been updated.
241
@@ -265,7 +265,7 @@ post-update
265 -----------
266
267 This hook is invoked by `git-receive-pack` on the remote repository,
268 -which happens when a `git push` is done on a local repository.
268 +which happens when a `git-push` is done on a local repository.
269 It executes on the remote repository once after all the refs have
270 been updated.
271
Documentation/gitignore.txt
+2 -2
@@ -92,7 +92,7 @@ Patterns have the following format:
92 An example:
93
94 --------------------------------------------------------------
95 - $ git-status
95 + $ git status
96 [...]
97 # Untracked files:
98 [...]
@@ -110,7 +110,7 @@ An example:
110 *.html
111 # except foo.html which is maintained by hand
112 !foo.html
113 - $ git-status
113 + $ git status
114 [...]
115 # Untracked files:
116 [...]
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.
69
70 objects/info/alternates::
@@ -85,7 +85,7 @@ objects/info/http-alternates::
85
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.
91
@@ -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, they need to be made executable.
138 Read linkgit:githooks[5] for more details about
139 each hook.
@@ -150,10 +150,10 @@ info/refs::
150 This file helps dumb transports discover what refs are
151 available in this repository. If the repository is
152 published for dumb transports, this file should be
153 - regenerated by `git update-server-info` every time a tag
153 + regenerated by `git-update-server-info` every time a tag
154 or branch is created or modified. This is normally done
155 from the `hooks/update` hook, which is run by the
156 - `git-receive-pack` command when you `git push` into the
156 + `git-receive-pack` command when you `git-push` into the
157 repository.
158
159 info/grafts::
@@ -167,14 +167,14 @@ info/grafts::
167 info/exclude::
168 This file, by convention among Porcelains, stores the
169 exclude pattern list. `.gitignore` is the per-directory
170 - ignore file. `git status`, `git add`, `git rm` and
171 - `git clean` look at it but the core git commands do not look
170 + ignore file. `git-status`, `git-add`, `git-rm` and
171 + `git-clean` look at it but the core git commands do not look
172 at it. See also: linkgit:gitignore[5].
173
174 remotes::
175 Stores shorthands to be used to give URL and default
176 refnames to interact with remote repository to
177 - `git fetch`, `git pull` and `git push` commands.
177 + `git-fetch`, `git-pull` and `git-push` commands.
178
179 logs::
180 Records of changes made to refs are stored in this
Documentation/gittutorial-2.txt
+9 -9
@@ -212,7 +212,7 @@ designate such an argument.
212 The index file
213 --------------
214
215 -The primary tool we've been using to create commits is "git commit
215 +The primary tool we've been using to create commits is "git-commit
216 -a", which creates a commit including every change you've made to
217 your working tree. But what if you want to commit changes only to
218 certain files? Or only certain changes to certain files?
@@ -255,7 +255,7 @@ index a042389..513feba 100644
255 +hello world, again
256 ------------------------------------------------
257
258 -So "git diff" is comparing against something other than the head.
258 +So "git-diff" is comparing against something other than the head.
259 The thing that it's comparing against is actually the index file,
260 which is stored in .git/index in a binary format, but whose contents
261 we can examine with ls-files:
@@ -270,9 +270,9 @@ hello world!
270 hello world, again
271 ------------------------------------------------
272
273 -So what our "git add" did was store a new blob and then put
273 +So what our "git-add" did was store a new blob and then put
274 a reference to it in the index file. If we modify the file again,
275 -we'll see that the new modifications are reflected in the "git diff"
275 +we'll see that the new modifications are reflected in the "git-diff"
276 output:
277
278 ------------------------------------------------
@@ -287,7 +287,7 @@ index 513feba..ba3da7b 100644
287 +again?
288 ------------------------------------------------
289
290 -With the right arguments, git diff can also show us the difference
290 +With the right arguments, git-diff can also show us the difference
291 between the working directory and the last commit, or between the
292 index and the last commit:
293
@@ -311,7 +311,7 @@ index a042389..513feba 100644
311 +hello world, again
312 ------------------------------------------------
313
314 -At any time, we can create a new commit using "git commit" (without
314 +At any time, we can create a new commit using "git-commit" (without
315 the -a option), and verify that the state committed only includes the
316 changes stored in the index file, not the additional change that is
317 still only in our working tree:
@@ -329,11 +329,11 @@ index 513feba..ba3da7b 100644
329 +again?
330 ------------------------------------------------
331
332 -So by default "git commit" uses the index to create the commit, not
332 +So by default "git-commit" uses the index to create the commit, not
333 the working tree; the -a option to commit tells it to first update
334 the index with all changes in the working tree.
335
336 -Finally, it's worth looking at the effect of "git add" on the index
336 +Finally, it's worth looking at the effect of "git-add" on the index
337 file:
338
339 ------------------------------------------------
@@ -341,7 +341,7 @@ $ echo "goodbye, world" >closing.txt
341 $ git add closing.txt
342 ------------------------------------------------
343
344 -The effect of the "git add" was to add one entry to the index file:
344 +The effect of the "git-add" was to add one entry to the index file:
345
346 ------------------------------------------------
347 $ git ls-files --stage
Documentation/gittutorial.txt
+15 -15
@@ -117,7 +117,7 @@ $ git commit
117 This will again prompt you for a message describing the change, and then
118 record a new version of the project.
119
120 -Alternatively, instead of running `git add` beforehand, you can use
120 +Alternatively, instead of running `git-add` beforehand, you can use
121
122 ------------------------------------------------
123 $ git commit -a
@@ -138,7 +138,7 @@ Git tracks content not files
138
139 Many revision control systems provide an "add" command that tells the
140 system to start tracking changes to a new file. Git's "add" command
141 -does something simpler and more powerful: `git add` is used both for new
141 +does something simpler and more powerful: `git-add` is used both for new
142 and newly modified files, and in both cases it takes a snapshot of the
143 given files and stages that content in the index, ready for inclusion in
144 the next commit.
@@ -316,7 +316,7 @@ $ git remote add bob /home/bob/myrepo
316 ------------------------------------------------
317
318 With this, Alice can perform the first operation alone using the
319 -"git fetch" command without merging them with her own branch,
319 +"git-fetch" command without merging them with her own branch,
320 using:
321
322 -------------------------------------
@@ -324,7 +324,7 @@ $ git fetch bob
324 -------------------------------------
325
326 Unlike the longhand form, when Alice fetches from Bob using a
327 -remote repository shorthand set up with `git remote`, what was
327 +remote repository shorthand set up with `git-remote`, what was
328 fetched is stored in a remote tracking branch, in this case
329 `bob/master`. So after this:
330
@@ -398,7 +398,7 @@ Exploring history
398 -----------------
399
400 Git history is represented as a series of interrelated commits. We
401 -have already seen that the git log command can list those commits.
401 +have already seen that the git-log command can list those commits.
402 Note that first line of each git log entry also gives a name for the
403 commit:
404
@@ -411,7 +411,7 @@ Date: Tue May 16 17:18:22 2006 -0700
411 merge-base: Clarify the comments on post processing.
412 -------------------------------------
413
414 -We can give this name to git show to see the details about this
414 +We can give this name to git-show to see the details about this
415 commit.
416
417 -------------------------------------
@@ -447,7 +447,7 @@ $ git show HEAD^2 # show the second parent of HEAD
447 You can also give commits names of your own; after running
448
449 -------------------------------------
450 -$ git-tag v2.5 1b2e1d63ff
450 +$ git tag v2.5 1b2e1d63ff
451 -------------------------------------
452
453 you can refer to 1b2e1d63ff by the name "v2.5". If you intend to
@@ -469,13 +469,13 @@ $ git reset --hard HEAD^ # reset your current branch and working
469 Be careful with that last command: in addition to losing any changes
470 in the working directory, it will also remove all later commits from
471 this branch. If this branch is the only branch containing those
472 -commits, they will be lost. Also, don't use "git reset" on a
472 +commits, they will be lost. Also, don't use "git-reset" on a
473 publicly-visible branch that other developers pull from, as it will
474 force needless merges on other developers to clean up the history.
475 If you need to undo changes that you have pushed, use linkgit:git-revert[1]
476 instead.
477
478 -The git grep command can search for strings in any version of your
478 +The git-grep command can search for strings in any version of your
479 project, so
480
481 -------------------------------------
@@ -484,7 +484,7 @@ $ git grep "hello" v2.5
484
485 searches for all occurrences of "hello" in v2.5.
486
487 -If you leave out the commit name, git grep will search any of the
487 +If you leave out the commit name, git-grep will search any of the
488 files it manages in your current directory. So
489
490 -------------------------------------
@@ -494,7 +494,7 @@ $ git grep "hello"
494 is a quick way to search just the files that are tracked by git.
495
496 Many git commands also take sets of commits, which can be specified
497 -in a number of ways. Here are some examples with git log:
497 +in a number of ways. Here are some examples with git-log:
498
499 -------------------------------------
500 $ git log v2.5..v2.6 # commits between v2.5 and v2.6
@@ -504,7 +504,7 @@ $ git log v2.5.. Makefile # commits since v2.5 which modify
504 # Makefile
505 -------------------------------------
506
507 -You can also give git log a "range" of commits where the first is not
507 +You can also give git-log a "range" of commits where the first is not
508 necessarily an ancestor of the second; for example, if the tips of
509 the branches "stable-release" and "master" diverged from a common
510 commit some time ago, then
@@ -523,9 +523,9 @@ $ git log experimental..stable
523 will show the list of commits made on the stable branch but not
524 the experimental branch.
525
526 -The "git log" command has a weakness: it must present commits in a
526 +The "git-log" command has a weakness: it must present commits in a
527 list. When the history has lines of development that diverged and
528 -then merged back together, the order in which "git log" presents
528 +then merged back together, the order in which "git-log" presents
529 those commits is meaningless.
530
531 Most projects with multiple contributors (such as the linux kernel,
@@ -549,7 +549,7 @@ of the file:
549 $ git diff v2.5:Makefile HEAD:Makefile.in
550 -------------------------------------
551
552 -You can also use "git show" to see any such file:
552 +You can also use "git-show" to see any such file:
553
554 -------------------------------------
555 $ git show v2.5:Makefile
Documentation/user-manual.txt
+38 -38
@@ -178,7 +178,7 @@ As you can see, a commit shows who made the latest change, what they
178 did, and why.
179
180 Every commit has a 40-hexdigit id, sometimes called the "object name" or the
181 -"SHA1 id", shown on the first line of the "git show" output. You can usually
181 +"SHA1 id", shown on the first line of the "git-show" output. You can usually
182 refer to a commit by a shorter name, such as a tag or a branch name, but this
183 longer name can also be useful. Most importantly, it is a globally unique
184 name for this commit: so if you tell somebody else the object name (for
@@ -390,7 +390,7 @@ references with the same shorthand name, see the "SPECIFYING
390 REVISIONS" section of linkgit:git-rev-parse[1].
391
392 [[Updating-a-repository-with-git-fetch]]
393 -Updating a repository with git fetch
393 +Updating a repository with git-fetch
394 ------------------------------------
395
396 Eventually the developer cloned from will do additional work in her
@@ -417,7 +417,7 @@ $ git fetch linux-nfs
417 -------------------------------------------------
418
419 New remote-tracking branches will be stored under the shorthand name
420 -that you gave "git remote add", in this case linux-nfs:
420 +that you gave "git-remote add", in this case linux-nfs:
421
422 -------------------------------------------------
423 $ git branch -r
@@ -1048,7 +1048,7 @@ $ git diff
1048
1049 shows the difference between the working tree and the index file.
1050
1051 -Note that "git add" always adds just the current contents of a file
1051 +Note that "git-add" always adds just the current contents of a file
1052 to the index; further changes to the same file will be ignored unless
1053 you run git-add on the file again.
1054
@@ -1111,7 +1111,7 @@ Ignoring files
1111 A project will often generate files that you do 'not' want to track with git.
1112 This typically includes files generated by a build process or temporary
1113 backup files made by your editor. Of course, 'not' tracking files with git
1114 -is just a matter of 'not' calling "`git add`" on them. But it quickly becomes
1114 +is just a matter of 'not' calling "`git-add`" on them. But it quickly becomes
1115 annoying to have these untracked files lying around; e.g. they make
1116 "`git add .`" and "`git commit -a`" practically useless, and they keep
1117 showing up in the output of "`git status`".
@@ -1449,7 +1449,7 @@ Checking out an old version of a file
1449
1450 In the process of undoing a previous bad change, you may find it
1451 useful to check out an older version of a particular file using
1452 -linkgit:git-checkout[1]. We've used git checkout before to switch
1452 +linkgit:git-checkout[1]. We've used git-checkout before to switch
1453 branches, but it has quite different behavior if it is given a path
1454 name: the command
1455
@@ -1651,7 +1651,7 @@ Sharing development with others
1651 ===============================
1652
1653 [[getting-updates-with-git-pull]]
1654 -Getting updates with git pull
1654 +Getting updates with git-pull
1655 -----------------------------
1656
1657 After you clone a repository and make a few changes of your own, you
@@ -1770,7 +1770,7 @@ Public git repositories
1770 Another way to submit changes to a project is to tell the maintainer
1771 of that project to pull the changes from your repository using
1772 linkgit:git-pull[1]. In the section "<<getting-updates-with-git-pull,
1773 -Getting updates with git pull>>" we described this as a way to get
1773 +Getting updates with git-pull>>" we described this as a way to get
1774 updates from the "main" repository, but it works just as well in the
1775 other direction.
1776
@@ -2735,7 +2735,7 @@ unless you've already created a reference of your own pointing to
2735 them.
2736
2737 [[forcing-fetch]]
2738 -Forcing git fetch to do non-fast-forward updates
2738 +Forcing git-fetch to do non-fast-forward updates
2739 ------------------------------------------------
2740
2741 If git fetch fails because the new head of a branch is not a
@@ -2810,7 +2810,7 @@ You can also add a "+" to force the update each time:
2810 $ git config remote.example.fetch +master:ref/remotes/example/master
2811 -------------------------------------------------
2812
2813 -Don't do this unless you're sure you won't mind "git fetch" possibly
2813 +Don't do this unless you're sure you won't mind "git-fetch" possibly
2814 throwing away commits on mybranch.
2815
2816 Also note that all of the above configuration can be performed by
@@ -3234,7 +3234,7 @@ it is with linkgit:git-fsck[1]; this may be time-consuming.
3234 Assume the output looks like this:
3235
3236 ------------------------------------------------
3237 -$ git-fsck --full
3237 +$ git fsck --full
3238 broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
3239 to blob 4b9458b3786228369c63936db65827de3cc06200
3240 missing blob 4b9458b3786228369c63936db65827de3cc06200
@@ -3464,14 +3464,14 @@ done
3464
3465 NOTE: Do not use local URLs here if you plan to publish your superproject!
3466
3467 -See what files `git submodule` created:
3467 +See what files `git-submodule` created:
3468
3469 -------------------------------------------------
3470 $ ls -a
3471 . .. .git .gitmodules a b c d
3472 -------------------------------------------------
3473
3474 -The `git submodule add` command does a couple of things:
3474 +The `git-submodule add` command does a couple of things:
3475
3476 - It clones the submodule under the current directory and by default checks out
3477 the master branch.
@@ -3517,7 +3517,7 @@ init` to add the submodule repository URLs to `.git/config`:
3517 $ git submodule init
3518 -------------------------------------------------
3519
3520 -Now use `git submodule update` to clone the repositories and check out the
3520 +Now use `git-submodule update` to clone the repositories and check out the
3521 commits specified in the superproject:
3522
3523 -------------------------------------------------
@@ -3527,8 +3527,8 @@ $ ls -a
3527 . .. .git a.txt
3528 -------------------------------------------------
3529
3530 -One major difference between `git submodule update` and `git submodule add` is
3531 -that `git submodule update` checks out a specific commit, rather than the tip
3530 +One major difference between `git-submodule update` and `git-submodule add` is
3531 +that `git-submodule update` checks out a specific commit, rather than the tip
3532 of a branch. It's like checking out a tag: the head is detached, so you're not
3533 working on a branch.
3534
@@ -3729,7 +3729,7 @@ unsaved state that you might want to restore later!) your current
3729 index. Normal operation is just
3730
3731 -------------------------------------------------
3732 -$ git-read-tree <sha1 of tree>
3732 +$ git read-tree <sha1 of tree>
3733 -------------------------------------------------
3734
3735 and your index file will now be equivalent to the tree that you saved
@@ -3752,7 +3752,7 @@ index file with read-tree, and then you need to check out the result
3752 with
3753
3754 -------------------------------------------------
3755 -$ git-checkout-index filename
3755 +$ git checkout-index filename
3756 -------------------------------------------------
3757
3758 or, if you want to check out all of the index, use `-a`.
@@ -3789,7 +3789,7 @@ You create a commit object by giving it the tree that describes the
3789 state at the time of the commit, and a list of parents:
3790
3791 -------------------------------------------------
3792 -$ git-commit-tree <tree> -p <parent> [-p <parent2> ..]
3792 +$ git commit-tree <tree> -p <parent> [-p <parent2> ..]
3793 -------------------------------------------------
3794
3795 and then giving the reason for the commit on stdin (either through
@@ -3852,14 +3852,14 @@ linkgit:git-cat-file[1] to examine details about the
3852 object:
3853
3854 -------------------------------------------------
3855 -$ git-cat-file -t <objectname>
3855 +$ git cat-file -t <objectname>
3856 -------------------------------------------------
3857
3858 shows the type of the object, and once you have the type (which is
3859 usually implicit in where you find the object), you can use
3860
3861 -------------------------------------------------
3862 -$ git-cat-file blob|tree|commit|tag <objectname>
3862 +$ git cat-file blob|tree|commit|tag <objectname>
3863 -------------------------------------------------
3864
3865 to show its contents. NOTE! Trees have binary content, and as a result
@@ -3873,7 +3873,7 @@ follow the convention of having the top commit name in `.git/HEAD`,
3873 you can do
3874
3875 -------------------------------------------------
3876 -$ git-cat-file commit HEAD
3876 +$ git cat-file commit HEAD
3877 -------------------------------------------------
3878
3879 to see what the top commit was.
@@ -3897,7 +3897,7 @@ To get the "base" for the merge, you first look up the common parent
3897 of two commits with
3898
3899 -------------------------------------------------
3900 -$ git-merge-base <commit1> <commit2>
3900 +$ git merge-base <commit1> <commit2>
3901 -------------------------------------------------
3902
3903 which will return you the commit they are both based on. You should
@@ -3905,7 +3905,7 @@ now look up the "tree" objects of those commits, which you can easily
3905 do with (for example)
3906
3907 -------------------------------------------------
3908 -$ git-cat-file commit <commitname> | head -1
3908 +$ git cat-file commit <commitname> | head -1
3909 -------------------------------------------------
3910
3911 since the tree object information is always the first line in a commit
@@ -3922,7 +3922,7 @@ you have in your current index anyway).
3922 To do the merge, do
3923
3924 -------------------------------------------------
3925 -$ git-read-tree -m -u <origtree> <yourtree> <targettree>
3925 +$ git read-tree -m -u <origtree> <yourtree> <targettree>
3926 -------------------------------------------------
3927
3928 which will do all trivial merge operations for you directly in the
@@ -3941,18 +3941,18 @@ entries" in it. Such an index tree can 'NOT' be written out to a tree
3941 object, and you will have to resolve any such merge clashes using
3942 other tools before you can write out the result.
3943
3944 -You can examine such index state with `git-ls-files --unmerged`
3944 +You can examine such index state with `git ls-files --unmerged`
3945 command. An example:
3946
3947 ------------------------------------------------
3948 -$ git-read-tree -m $orig HEAD $target
3949 -$ git-ls-files --unmerged
3948 +$ git read-tree -m $orig HEAD $target
3949 +$ git ls-files --unmerged
3950 100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c
3951 100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c
3952 100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c
3953 ------------------------------------------------
3954
3955 -Each line of the `git-ls-files --unmerged` output begins with
3955 +Each line of the `git ls-files --unmerged` output begins with
3956 the blob mode bits, blob SHA1, 'stage number', and the
3957 filename. The 'stage number' is git's way to say which tree it
3958 came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD`
@@ -3970,9 +3970,9 @@ program, e.g. `diff3`, `merge`, or git's own merge-file, on
3970 the blob objects from these three stages yourself, like this:
3971
3972 ------------------------------------------------
3973 -$ git-cat-file blob 263414f... >hello.c~1
3974 -$ git-cat-file blob 06fa6a2... >hello.c~2
3975 -$ git-cat-file blob cc44c73... >hello.c~3
3973 +$ git cat-file blob 263414f... >hello.c~1
3974 +$ git cat-file blob 06fa6a2... >hello.c~2
3975 +$ git cat-file blob cc44c73... >hello.c~3
3976 $ git merge-file hello.c~2 hello.c~1 hello.c~3
3977 ------------------------------------------------
3978
@@ -3983,7 +3983,7 @@ merge result for this file is by:
3983
3984 -------------------------------------------------
3985 $ mv -f hello.c~2 hello.c
3986 -$ git-update-index hello.c
3986 +$ git update-index hello.c
3987 -------------------------------------------------
3988
3989 When a path is in unmerged state, running `git-update-index` for
@@ -3996,10 +3996,10 @@ for this. There is `git-merge-index` program that extracts the
3996 stages to temporary files and calls a "merge" script on it:
3997
3998 -------------------------------------------------
3999 -$ git-merge-index git-merge-one-file hello.c
3999 +$ git merge-index git-merge-one-file hello.c
4000 -------------------------------------------------
4001
4002 -and that is what higher level `git merge -s resolve` is implemented with.
4002 +and that is what higher level `git-merge -s resolve` is implemented with.
4003
4004 [[hacking-git]]
4005 Hacking git
@@ -4127,7 +4127,7 @@ commits one by one with the function `get_revision()`.
4127
4128 If you are interested in more details of the revision walking process,
4129 just have a look at the first implementation of `cmd_log()`; call
4130 -`git-show v1.3.0{tilde}155^2{tilde}4` and scroll down to that function (note that you
4130 +`git show v1.3.0{tilde}155^2{tilde}4` and scroll down to that function (note that you
4131 no longer need to call `setup_pager()` directly).
4132
4133 Nowadays, `git log` is a builtin, which means that it is _contained_ in the
@@ -4218,10 +4218,10 @@ To find out how the result can be used, just read on in `cmd_cat_file()`:
4218 -----------------------------------
4219
4220 Sometimes, you do not know where to look for a feature. In many such cases,
4221 -it helps to search through the output of `git log`, and then `git show` the
4221 +it helps to search through the output of `git log`, and then `git-show` the
4222 corresponding commit.
4223
4224 -Example: If you know that there was some test case for `git bundle`, but
4224 +Example: If you know that there was some test case for `git-bundle`, but
4225 do not remember where it was (yes, you _could_ `git grep bundle t/`, but that
4226 does not illustrate the point!):
4227