path: root/Documentation/user-manual.txt
diff options
authorJonathan Nieder <>2008-06-30 06:09:04 (GMT)
committerJunio C Hamano <>2008-07-02 00:20:15 (GMT)
commitb1889c36d85514e5e70462294c561a02c2edfe2b (patch)
tree9a171d7e3fb8063c239a2c9c4dcec744a202de07 /Documentation/user-manual.txt
parent46e56e81b3bc91af7071809fbda8dcdec22c4cb1 (diff)
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 <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to 'Documentation/user-manual.txt')
1 files changed, 38 insertions, 38 deletions
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 36ab372..ca13266 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
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
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 "<<getting-updates-with-git-pull,
-Getting updates with git pull>>" 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
-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 <sha1 of tree>
+$ git read-tree <sha1 of 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
-$ 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 <tree> -p <parent> [-p <parent2> ..]
+$ git commit-tree <tree> -p <parent> [-p <parent2> ..]
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
-$ git-cat-file -t <objectname>
+$ git cat-file -t <objectname>
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 <objectname>
+$ git cat-file blob|tree|commit|tag <objectname>
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 <commit1> <commit2>
+$ git merge-base <commit1> <commit2>
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 <commitname> | head -1
+$ git cat-file commit <commitname> | 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 <origtree> <yourtree> <targettree>
+$ git read-tree -m -u <origtree> <yourtree> <targettree>
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
@@ -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!):