@matheusbsbs / matheus-bagliano / commits / 467c0197fd

Fork 0

Documentation: more "git-" versus "git " changes

With git-commands moving out of $(bindir), it is useful to make a clearer distinction between the git subcommand 'git-whatever' and the command you type, `git whatever <options>`. So we use a dash after "git" when referring to the former and not the latter. I already sent a patch doing this same thing, but I missed some spots. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Jonathan Nieder committed Jul 3, 2008 at 00:28 UTC 467c0197fd0a49078d05839ee385046cd3707a5b

13 files changed +71 -71

Documentation/config.txt

+26 -26

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

356

357 core.whitespace::

358 A comma separated list of common whitespace problems to

359 - notice. `git diff` will use `color.diff.whitespace` to

360 - highlight them, and `git apply --whitespace=error` will

359 + notice. `git-diff` will use `color.diff.whitespace` to

360 + highlight them, and `git-apply --whitespace=error` will

361 consider them as errors:

362 +

363 * `trailing-space` treats trailing whitespaces at the end of the line

@@ -426,20 +426,20 @@ branch.autosetuprebase::

426 This option defaults to never.

427

428 branch.<name>.remote::

429 - When in branch <name>, it tells `git fetch` which remote to fetch.

430 - If this option is not given, `git fetch` defaults to remote "origin".

429 + When in branch <name>, it tells `git-fetch` which remote to fetch.

430 + If this option is not given, `git-fetch` defaults to remote "origin".

431

432 branch.<name>.merge::

433 - When in branch <name>, it tells `git fetch` the default

433 + When in branch <name>, it tells `git-fetch` the default

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

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

436 ref which is fetched from the remote given by

437 "branch.<name>.remote".

438 - The merge information is used by `git pull` (which at first calls

439 - `git fetch`) to lookup the default branch for merging. Without

440 - this option, `git pull` defaults to merge the first refspec fetched.

438 + The merge information is used by `git-pull` (which at first calls

439 + `git-fetch`) to lookup the default branch for merging. Without

440 + this option, `git-pull` defaults to merge the first refspec fetched.

441 Specify multiple values to get an octopus merge.

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

442 + If you wish to setup `git-pull` so that it merges into <name> from

443 another branch in the local repository, you can point

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

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

@@ -508,12 +508,12 @@ color.diff.<slot>::

508

509 color.interactive::

510 When set to `always`, always use colors for interactive prompts

511 - and displays (such as those used by "git add --interactive").

511 + and displays (such as those used by "git-add --interactive").

512 When false (or `never`), never. When set to `true` or `auto`, use

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

514

515 color.interactive.<slot>::

516 - Use customized color for `git add --interactive`

516 + Use customized color for `git-add --interactive`

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

518 three distinct types of normal output from interactive

519 programs. The values of these variables may be specified as

@@ -550,14 +550,14 @@ color.ui::

550 take precedence over this setting. Defaults to false.

551

552 diff.autorefreshindex::

553 - When using `git diff` to compare with work tree

553 + When using `git-diff` to compare with work tree

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

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

556 update the cached stat information for paths whose

557 contents in the work tree match the contents in the

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

559 - affects only `git diff` Porcelain, and not lower level

560 - `diff` commands, such as `git diff-files`.

559 + affects only `git-diff` Porcelain, and not lower level

560 + `diff` commands, such as `git-diff-files`.

561

562 diff.external::

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

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

568

569 diff.renameLimit::

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

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

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

572

573 diff.renames::

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

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

608

609 gc.aggressiveWindow::

610 The window size parameter used in the delta compression

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

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

612 to 10.

613

614 gc.auto::

@@ -625,37 +625,37 @@ gc.autopacklimit::

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

626

627 gc.packrefs::

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

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

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

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

630 + from the repository. Setting this to `true` lets `git-gc`

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

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

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

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

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

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

636 - prevent `git pack-refs` from being run from `git gc`.

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

637

638 gc.pruneexpire::

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

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

640 Override the grace period with this config variable.

641

642 gc.reflogexpire::

643 - `git reflog expire` removes reflog entries older than

643 + `git-reflog expire` removes reflog entries older than

644 this time; defaults to 90 days.

645

646 gc.reflogexpireunreachable::

647 - `git reflog expire` removes reflog entries older than

647 + `git-reflog expire` removes reflog entries older than

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

649 defaults to 30 days.

650

651 gc.rerereresolved::

652 Records of conflicted merge you resolved earlier are

653 - kept for this many days when `git rerere gc` is run.

653 + kept for this many days when `git-rerere gc` is run.

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

655

656 gc.rerereunresolved::

657 Records of conflicted merge you have not resolved are

658 - kept for this many days when `git rerere gc` is run.

658 + kept for this many days when `git-rerere gc` is run.

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

660

661 rerere.enabled::

@@ -844,7 +844,7 @@ instaweb.port::

844

845 log.date::

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

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

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

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

849 See linkgit:git-log[1].

850

Documentation/git-bisect.txt

+2 -2

@@ -26,7 +26,7 @@ on the subcommand:

26 git bisect log

27 git bisect run <cmd>...

29 -This command uses `git rev-list --bisect` to help drive the

29 +This command uses `git-rev-list --bisect` 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.

@@ -101,7 +101,7 @@ $ git bisect visualize

101 to see the currently remaining suspects in `gitk`. `visualize` is a bit

102 too long to type and `view` is provided as a synonym.

103

104 -If `DISPLAY` environment variable is not set, `git log` is used

104 +If 'DISPLAY' environment variable is not set, `git-log` is used

105 instead. You can even give command line options such as `-p` and

106 `--stat`.

107

Documentation/git-commit.txt

+1 -1

@@ -155,7 +155,7 @@ but can be used to amend a merge commit.

155 Make a commit only from the paths specified on the

156 command line, disregarding any contents that have been

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

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

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

159 in which case this option can be omitted.

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

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

Documentation/git-filter-branch.txt

+1 -1

@@ -163,7 +163,7 @@ to other tags will be rewritten to point to the underlying commit.

163

164 -f::

165 --force::

166 - `git filter-branch` refuses to start with an existing temporary

166 + `git-filter-branch` refuses to start with an existing temporary

167 directory or when there are already refs starting with

168 'refs/original/', unless forced.

169

Documentation/git-format-patch.txt

+1 -1

@@ -190,7 +190,7 @@ EXAMPLES

190 the current branch using `git-am` to cherry-pick them:

191 +

192 ------------

193 -$ git format-patch -k --stdout R1..R2 | git-am -3 -k

193 +$ git format-patch -k --stdout R1..R2 | git am -3 -k

194 ------------

195

196 * Extract all commits which are in the current branch but not in the

Documentation/git-help.txt

+1 -1

@@ -120,7 +120,7 @@ man.<tool>.path

120 You can explicitly provide a full path to your preferred man viewer by

121 setting the configuration variable 'man.<tool>.path'. For example, you

122 can configure the absolute path to konqueror by setting

123 -'man.konqueror.path'. Otherwise, 'git help' assumes the tool is

123 +'man.konqueror.path'. Otherwise, 'git-help' assumes the tool is

124 available in PATH.

125

126 man.<tool>.cmd

Documentation/git-rebase.txt

+2 -2

@@ -259,10 +259,10 @@ NOTES

259 When you rebase a branch, you are changing its history in a way that

260 will cause problems for anyone who already has a copy of the branch

261 in their repository and tries to pull updates from you. You should

262 -understand the implications of using 'git rebase' on a repository that

262 +understand the implications of using 'git-rebase' on a repository that

263 you share.

264

265 -When the git rebase command is run, it will first execute a "pre-rebase"

265 +When the git-rebase command is run, it will first execute a "pre-rebase"

266 hook if one exists. You can use this hook to do sanity checks and

267 reject the rebase if it isn't appropriate. Please see the template

268 pre-rebase hook script for an example.

Documentation/git-reflog.txt

+1 -1

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

60 refs.

61 +

62 This computation involves traversing all the reachable objects, i.e. it

63 -has the same cost as 'git prune'. Fortunately, once this is run, we

63 +has the same cost as 'git-prune'. Fortunately, once this is run, we

64 should not have to ever worry about missing objects, because the current

65 prune and pack-objects know about reflogs and protect objects referred by

66 them.

Documentation/git-remote.txt

+1 -1

@@ -124,7 +124,7 @@ $ git checkout -b nfs linux-nfs/master

124 ...

125 ------------

126

127 -* Imitate 'git clone' but track only selected branches

127 +* Imitate 'git-clone' but track only selected branches

128 +

129 ------------

130 $ mkdir project.git

Documentation/git-rerere.txt

+1 -1

@@ -163,7 +163,7 @@ If this three-way merge resolves cleanly, the result is written

163 out to your working tree file, so you would not have to manually

164 resolve it. Note that `git-rerere` leaves the index file alone,

165 so you still need to do the final sanity checks with `git diff`

166 -(or `git diff -c`) and `git add` when you are satisfied.

166 +(or `git diff -c`) and `git-add` when you are satisfied.

167

168 As a convenience measure, `git-merge` automatically invokes

169 `git-rerere` when it exits with a failed automerge, which

Documentation/git-shortlog.txt

+1 -1

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

4 NAME

5 ----

6 -git-shortlog - Summarize 'git log' output

6 +git-shortlog - Summarize 'git-log' output

8 SYNOPSIS

9 --------

Documentation/gitcore-tutorial.txt

+15 -15

@@ -595,7 +595,7 @@ pointer to the state you want to tag, but also a small tag name and

595 message, along with optionally a PGP signature that says that yes,

596 you really did

597 that tag. You create these annotated tags with either the `-a` or

598 -`-s` flag to `git tag`:

598 +`-s` flag to `git-tag`:

599

600 ----------------

601 $ git tag -s <tagname>

@@ -642,7 +642,7 @@ and it will be gone. There's no external repository, and there's no

642 history outside the project you created.

643

644 - if you want to move or duplicate a git repository, you can do so. There

645 - is `git clone` command, but if all you want to do is just to

645 + is `git-clone` command, but if all you want to do is just to

646 create a copy of your repository (with all the full history that

647 went along with it), you can do so with a regular

648 `cp -a git-tutorial new-git-tutorial`.

@@ -776,7 +776,7 @@ to it.

776 ================================================

777 If you make the decision to start your new branch at some

778 other point in the history than the current `HEAD`, you can do so by

779 -just telling `git checkout` what the base of the checkout would be.

779 +just telling `git-checkout` what the base of the checkout would be.

780 In other words, if you have an earlier tag or branch, you'd just do

781

782 ------------

@@ -819,7 +819,7 @@ $ git branch <branchname> [startingpoint]

819

820 which will simply _create_ the branch, but will not do anything further.

821 You can then later -- once you decide that you want to actually develop

822 -on that branch -- switch to that branch with a regular `git checkout`

822 +on that branch -- switch to that branch with a regular `git-checkout`

823 with the branchname as the argument.

824

825

@@ -881,7 +881,7 @@ source.

881 Anyway, let's exit `gitk` (`^Q` or the File menu), and decide that we want

882 to merge the work we did on the `mybranch` branch into the `master`

883 branch (which is currently our `HEAD` too). To do that, there's a nice

884 -script called `git merge`, which wants to know which branches you want

884 +script called `git-merge`, which wants to know which branches you want

885 to resolve and what the merge is all about:

886

887 ------------

@@ -1023,12 +1023,12 @@ Merging external work

1023 It's usually much more common that you merge with somebody else than

1024 merging with your own branches, so it's worth pointing out that git

1025 makes that very easy too, and in fact, it's not that different from

1026 -doing a `git merge`. In fact, a remote merge ends up being nothing

1026 +doing a `git-merge`. In fact, a remote merge ends up being nothing

1027 more than "fetch the work from a remote repository into a temporary tag"

1028 -followed by a `git merge`.

1028 +followed by a `git-merge`.

1029

1030 Fetching from a remote repository is done by, unsurprisingly,

1031 -`git fetch`:

1031 +`git-fetch`:

1032

1033 ----------------

1034 $ git fetch <remote-repository>

@@ -1115,7 +1115,7 @@ argument.

1115 [NOTE]

1116 You could do without using any branches at all, by

1117 keeping as many local repositories as you would like to have

1118 -branches, and merging between them with `git pull`, just like

1118 +branches, and merging between them with `git-pull`, just like

1119 you merge between branches. The advantage of this approach is

1120 that it lets you keep a set of files for each `branch` checked

1121 out and you may find it easier to switch back and forth if you

@@ -1132,7 +1132,7 @@ like this:

1132 $ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/

1133 ------------------------------------------------

1134

1135 -and use the "linus" keyword with `git pull` instead of the full URL.

1135 +and use the "linus" keyword with `git-pull` instead of the full URL.

1136

1137 Examples.

1138

@@ -1168,7 +1168,7 @@ $ git show-branch --more=2 master mybranch

1168 +* [master^] Some fun.

1169 ------------

1170

1171 -Remember, before running `git merge`, our `master` head was at

1171 +Remember, before running `git-merge`, our `master` head was at

1172 "Some fun." commit, while our `mybranch` head was at "Some

1173 work." commit.

1174

@@ -1345,7 +1345,7 @@ $ mkdir my-git.git

1345 ------------

1346

1347 Then, make that directory into a git repository by running

1348 -`git init`, but this time, since its name is not the usual

1348 +`git-init`, but this time, since its name is not the usual

1349 `.git`, we do things slightly differently:

1350

1351 ------------

@@ -1407,7 +1407,7 @@ $ git repack

1407

1408 will do it for you. If you followed the tutorial examples, you

1409 would have accumulated about 17 objects in `.git/objects/??/`

1410 -directories by now. `git repack` tells you how many objects it

1410 +directories by now. `git-repack` tells you how many objects it

1411 packed, and stores the packed file in `.git/objects/pack`

1412 directory.

1413

@@ -1656,8 +1656,8 @@ $ git reset --hard master~2

1656 ------------

1657

1658 You can make sure 'git show-branch' matches the state before

1659 -those two 'git merge' you just did. Then, instead of running

1660 -two 'git merge' commands in a row, you would merge these two

1659 +those two 'git-merge' you just did. Then, instead of running

1660 +two 'git-merge' commands in a row, you would merge these two

1661 branch heads (this is known as 'making an Octopus'):

1662

1663 ------------

Documentation/user-manual.txt

+18 -18

@@ -1963,10 +1963,10 @@ error: failed to push to 'ssh://yourserver.com/~you/proj.git'

1963

1964 This can happen, for example, if you:

1965

1966 - - use `git reset --hard` to remove already-published commits, or

1967 - - use `git commit --amend` to replace already-published commits

1966 + - use `git-reset --hard` to remove already-published commits, or

1967 + - use `git-commit --amend` to replace already-published commits

1968 (as in <<fixing-a-mistake-by-rewriting-history>>), or

1969 - - use `git rebase` to rebase any already-published commits (as

1969 + - use `git-rebase` to rebase any already-published commits (as

1970 in <<using-git-rebase>>).

1971

1972 You may force git-push to perform the update anyway by preceding the

@@ -2170,7 +2170,7 @@ they are for, or what status they are in. To get a reminder of what

2170 changes are in a specific branch, use:

2171

2172 -------------------------------------------------

2173 -$ git log linux..branchname | git-shortlog

2173 +$ git log linux..branchname | git shortlog

2174 -------------------------------------------------

2175

2176 To see whether it has already been merged into the test or release branches,

@@ -2443,7 +2443,7 @@ patches to the new mywork. The result will look like:

2443 ................................................

2444

2445 In the process, it may discover conflicts. In that case it will stop

2446 -and allow you to fix the conflicts; after fixing conflicts, use "git add"

2446 +and allow you to fix the conflicts; after fixing conflicts, use "git-add"

2447 to update the index with those contents, and then, instead of

2448 running git-commit, just run

2449

@@ -2700,7 +2700,7 @@ master branch. In more detail:

2700 git fetch and fast-forwards

2701 ---------------------------

2702

2703 -In the previous example, when updating an existing branch, "git fetch"

2703 +In the previous example, when updating an existing branch, "git-fetch"

2704 checks to make sure that the most recent commit on the remote

2705 branch is a descendant of the most recent commit on your copy of the

2706 branch before updating your copy of the branch to point at the new

@@ -2726,7 +2726,7 @@ resulting in a situation like:

2726 o--o--o <-- new head of the branch

2727 ................................................

2728

2729 -In this case, "git fetch" will fail, and print out a warning.

2729 +In this case, "git-fetch" will fail, and print out a warning.

2730

2731 In that case, you can still force git to update to the new head, as

2732 described in the following section. However, note that in the

@@ -3106,7 +3106,7 @@ $ git prune

3106

3107 to remove any of the "loose" objects that are now contained in the

3108 pack. This will also remove any unreferenced objects (which may be

3109 -created when, for example, you use "git reset" to remove a commit).

3109 +created when, for example, you use "git-reset" to remove a commit).

3110 You can verify that the loose objects are gone by looking at the

3111 .git/objects directory or by running

3112

@@ -3135,7 +3135,7 @@ branch still exists, as does everything it pointed to. The branch

3135 pointer itself just doesn't, since you replaced it with another one.

3136

3137 There are also other situations that cause dangling objects. For

3138 -example, a "dangling blob" may arise because you did a "git add" of a

3138 +example, a "dangling blob" may arise because you did a "git-add" of a

3139 file, but then, before you actually committed it and made it part of the

3140 bigger picture, you changed something else in that file and committed

3141 that *updated* thing--the old state that you added originally ends up

@@ -3185,7 +3185,7 @@ Usually, dangling blobs and trees aren't very interesting. They're

3185 almost always the result of either being a half-way mergebase (the blob

3186 will often even have the conflict markers from a merge in it, if you

3187 have had conflicting merges that you fixed up by hand), or simply

3188 -because you interrupted a "git fetch" with ^C or something like that,

3188 +because you interrupted a "git-fetch" with ^C or something like that,

3189 leaving _some_ of the new objects in the object database, but just

3190 dangling and useless.

3191

@@ -3694,7 +3694,7 @@ removed. The only thing `--remove` means is that update-index will be

3694 considering a removed file to be a valid thing, and if the file really

3695 does not exist any more, it will update the index accordingly.

3696

3697 -As a special case, you can also do `git-update-index --refresh`, which

3697 +As a special case, you can also do `git update-index --refresh`, which

3698 will refresh the "stat" information of each index to match the current

3699 stat information. It will 'not' update the object status itself, and

3700 it will only update the fields that are used to quickly test whether

@@ -3770,7 +3770,7 @@ from one representation to the other:

3770 Tying it all together

3771 ~~~~~~~~~~~~~~~~~~~~~

3772

3773 -To commit a tree you have instantiated with "git-write-tree", you'd

3773 +To commit a tree you have instantiated with "git write-tree", you'd

3774 create a "commit" object that refers to that tree and the history

3775 behind it--most notably the "parent" commits that preceded it in

3776 history.

@@ -3927,7 +3927,7 @@ $ git read-tree -m -u <origtree> <yourtree> <targettree>

3927

3928 which will do all trivial merge operations for you directly in the

3929 index file, and you can just write the result out with

3930 -`git-write-tree`.

3930 +`git write-tree`.

3931

3932

3933 [[merging-multiple-trees-2]]

@@ -4095,7 +4095,7 @@ functions like `get_sha1_basic()` or the likes.

4095 This is just to get you into the groove for the most libified part of Git:

4096 the revision walker.

4097

4098 -Basically, the initial version of `git log` was a shell script:

4098 +Basically, the initial version of `git-log` was a shell script:

4099

4100 ----------------------------------------------------------------

4101 $ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \

@@ -4130,7 +4130,7 @@ 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

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

4133 +Nowadays, `git-log` is a builtin, which means that it is _contained_ in the

4134 command `git`. The source side of a builtin is

4135

4136 - a function called `cmd_<bla>`, typically defined in `builtin-<bla>.c`,

@@ -4146,7 +4146,7 @@ since they share quite a bit of code. In that case, the commands which are

4146 _not_ named like the `.c` file in which they live have to be listed in

4147 `BUILT_INS` in the `Makefile`.

4148

4149 -`git log` looks more complicated in C than it does in the original script,

4149 +`git-log` looks more complicated in C than it does in the original script,

4150 but that allows for a much greater flexibility and performance.

4151

4152 Here again it is a good point to take a pause.

@@ -4157,9 +4157,9 @@ the organization of Git (after you know the basic concepts).

4157 So, think about something which you are interested in, say, "how can I

4158 access a blob just knowing the object name of it?". The first step is to

4159 find a Git command with which you can do it. In this example, it is either

4160 -`git show` or `git cat-file`.

4160 +`git-show` or `git-cat-file`.

4161

4162 -For the sake of clarity, let's stay with `git cat-file`, because it

4162 +For the sake of clarity, let's stay with `git-cat-file`, because it

4163

4164 - is plumbing, and

4165