From b1889c36d85514e5e70462294c561a02c2edfe2b Mon Sep 17 00:00:00 2001 From: Jonathan Nieder Date: Mon, 30 Jun 2008 01:09:04 -0500 Subject: Documentation: be consistent about "git-" versus "git " Since the git-* commands are not installed in $(bindir), using "git-command " 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 Signed-off-by: Junio C Hamano --- Documentation/user-manual.txt | 76 +++++++++++++++++++++---------------------- 1 file changed, 38 insertions(+), 38 deletions(-) (limited to 'Documentation/user-manual.txt') diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 36ab372204..ca13266b11 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -178,7 +178,7 @@ As you can see, a commit shows who made the latest change, what they did, and why. Every commit has a 40-hexdigit id, sometimes called the "object name" or the -"SHA1 id", shown on the first line of the "git show" output. You can usually +"SHA1 id", shown on the first line of the "git-show" output. You can usually refer to a commit by a shorter name, such as a tag or a branch name, but this longer name can also be useful. Most importantly, it is a globally unique 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 REVISIONS" section of linkgit:git-rev-parse[1]. [[Updating-a-repository-with-git-fetch]] -Updating a repository with git fetch +Updating a repository with git-fetch ------------------------------------ Eventually the developer cloned from will do additional work in her @@ -417,7 +417,7 @@ $ git fetch linux-nfs ------------------------------------------------- New remote-tracking branches will be stored under the shorthand name -that you gave "git remote add", in this case linux-nfs: +that you gave "git-remote add", in this case linux-nfs: ------------------------------------------------- $ git branch -r @@ -1048,7 +1048,7 @@ $ git diff shows the difference between the working tree and the index file. -Note that "git add" always adds just the current contents of a file +Note that "git-add" always adds just the current contents of a file to the index; further changes to the same file will be ignored unless you run git-add on the file again. @@ -1111,7 +1111,7 @@ Ignoring files A project will often generate files that you do 'not' want to track with git. This typically includes files generated by a build process or temporary backup files made by your editor. Of course, 'not' tracking files with git -is just a matter of 'not' calling "`git add`" on them. But it quickly becomes +is just a matter of 'not' calling "`git-add`" on them. But it quickly becomes annoying to have these untracked files lying around; e.g. they make "`git add .`" and "`git commit -a`" practically useless, and they keep showing up in the output of "`git status`". @@ -1449,7 +1449,7 @@ Checking out an old version of a file In the process of undoing a previous bad change, you may find it useful to check out an older version of a particular file using -linkgit:git-checkout[1]. We've used git checkout before to switch +linkgit:git-checkout[1]. We've used git-checkout before to switch branches, but it has quite different behavior if it is given a path name: the command @@ -1651,7 +1651,7 @@ Sharing development with others =============================== [[getting-updates-with-git-pull]] -Getting updates with git pull +Getting updates with git-pull ----------------------------- After you clone a repository and make a few changes of your own, you @@ -1770,7 +1770,7 @@ Public git repositories Another way to submit changes to a project is to tell the maintainer of that project to pull the changes from your repository using linkgit:git-pull[1]. In the section "<>" we described this as a way to get +Getting updates with git-pull>>" we described this as a way to get updates from the "main" repository, but it works just as well in the other direction. @@ -2735,7 +2735,7 @@ unless you've already created a reference of your own pointing to them. [[forcing-fetch]] -Forcing git fetch to do non-fast-forward updates +Forcing git-fetch to do non-fast-forward updates ------------------------------------------------ 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: $ git config remote.example.fetch +master:ref/remotes/example/master ------------------------------------------------- -Don't do this unless you're sure you won't mind "git fetch" possibly +Don't do this unless you're sure you won't mind "git-fetch" possibly throwing away commits on mybranch. 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. Assume the output looks like this: ------------------------------------------------ -$ git-fsck --full +$ git fsck --full broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8 to blob 4b9458b3786228369c63936db65827de3cc06200 missing blob 4b9458b3786228369c63936db65827de3cc06200 @@ -3464,14 +3464,14 @@ done NOTE: Do not use local URLs here if you plan to publish your superproject! -See what files `git submodule` created: +See what files `git-submodule` created: ------------------------------------------------- $ ls -a . .. .git .gitmodules a b c d ------------------------------------------------- -The `git submodule add` command does a couple of things: +The `git-submodule add` command does a couple of things: - It clones the submodule under the current directory and by default checks out the master branch. @@ -3517,7 +3517,7 @@ init` to add the submodule repository URLs to `.git/config`: $ git submodule init ------------------------------------------------- -Now use `git submodule update` to clone the repositories and check out the +Now use `git-submodule update` to clone the repositories and check out the commits specified in the superproject: ------------------------------------------------- @@ -3527,8 +3527,8 @@ $ ls -a . .. .git a.txt ------------------------------------------------- -One major difference between `git submodule update` and `git submodule add` is -that `git submodule update` checks out a specific commit, rather than the tip +One major difference between `git-submodule update` and `git-submodule add` is +that `git-submodule update` checks out a specific commit, rather than the tip of a branch. It's like checking out a tag: the head is detached, so you're not working on a branch. @@ -3729,7 +3729,7 @@ unsaved state that you might want to restore later!) your current index. Normal operation is just ------------------------------------------------- -$ git-read-tree +$ git read-tree ------------------------------------------------- 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 with ------------------------------------------------- -$ git-checkout-index filename +$ git checkout-index filename ------------------------------------------------- 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 state at the time of the commit, and a list of parents: ------------------------------------------------- -$ git-commit-tree -p [-p ..] +$ git commit-tree -p [-p ..] ------------------------------------------------- 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 object: ------------------------------------------------- -$ git-cat-file -t +$ git cat-file -t ------------------------------------------------- shows the type of the object, and once you have the type (which is usually implicit in where you find the object), you can use ------------------------------------------------- -$ git-cat-file blob|tree|commit|tag +$ git cat-file blob|tree|commit|tag ------------------------------------------------- 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`, you can do ------------------------------------------------- -$ git-cat-file commit HEAD +$ git cat-file commit HEAD ------------------------------------------------- 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 of two commits with ------------------------------------------------- -$ git-merge-base +$ git merge-base ------------------------------------------------- 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 do with (for example) ------------------------------------------------- -$ git-cat-file commit | head -1 +$ git cat-file commit | head -1 ------------------------------------------------- since the tree object information is always the first line in a commit @@ -3922,7 +3922,7 @@ you have in your current index anyway). To do the merge, do ------------------------------------------------- -$ git-read-tree -m -u +$ git read-tree -m -u ------------------------------------------------- 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 object, and you will have to resolve any such merge clashes using other tools before you can write out the result. -You can examine such index state with `git-ls-files --unmerged` +You can examine such index state with `git ls-files --unmerged` command. An example: ------------------------------------------------ -$ git-read-tree -m $orig HEAD $target -$ git-ls-files --unmerged +$ git read-tree -m $orig HEAD $target +$ git ls-files --unmerged 100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c 100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c 100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c ------------------------------------------------ -Each line of the `git-ls-files --unmerged` output begins with +Each line of the `git ls-files --unmerged` output begins with the blob mode bits, blob SHA1, 'stage number', and the filename. The 'stage number' is git's way to say which tree it 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 the blob objects from these three stages yourself, like this: ------------------------------------------------ -$ git-cat-file blob 263414f... >hello.c~1 -$ git-cat-file blob 06fa6a2... >hello.c~2 -$ git-cat-file blob cc44c73... >hello.c~3 +$ git cat-file blob 263414f... >hello.c~1 +$ git cat-file blob 06fa6a2... >hello.c~2 +$ git cat-file blob cc44c73... >hello.c~3 $ git merge-file hello.c~2 hello.c~1 hello.c~3 ------------------------------------------------ @@ -3983,7 +3983,7 @@ merge result for this file is by: ------------------------------------------------- $ mv -f hello.c~2 hello.c -$ git-update-index hello.c +$ git update-index hello.c ------------------------------------------------- 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 stages to temporary files and calls a "merge" script on it: ------------------------------------------------- -$ git-merge-index git-merge-one-file hello.c +$ git merge-index git-merge-one-file hello.c ------------------------------------------------- -and that is what higher level `git merge -s resolve` is implemented with. +and that is what higher level `git-merge -s resolve` is implemented with. [[hacking-git]] Hacking git @@ -4127,7 +4127,7 @@ commits one by one with the function `get_revision()`. If you are interested in more details of the revision walking process, just have a look at the first implementation of `cmd_log()`; call -`git-show v1.3.0{tilde}155^2{tilde}4` and scroll down to that function (note that you +`git show v1.3.0{tilde}155^2{tilde}4` and scroll down to that function (note that you no longer need to call `setup_pager()` directly). 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()`: ----------------------------------- Sometimes, you do not know where to look for a feature. In many such cases, -it helps to search through the output of `git log`, and then `git show` the +it helps to search through the output of `git log`, and then `git-show` the corresponding commit. -Example: If you know that there was some test case for `git bundle`, but +Example: If you know that there was some test case for `git-bundle`, but do not remember where it was (yes, you _could_ `git grep bundle t/`, but that does not illustrate the point!): -- cgit v1.2.3