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>
maint
Jonathan Nieder17 years agocommitted byJunio C Hamano
@ -9,7 +9,7 @@ git-apply - Apply a patch on a git index file and a working tree
@@ -9,7 +9,7 @@ git-apply - Apply a patch on a git index file and a working tree
@ -8,7 +8,7 @@ git-blame - Show what revision and author last modified each line of a file
@@ -8,7 +8,7 @@ git-blame - Show what revision and author last modified each line of a file
@ -9,10 +9,10 @@ git-bundle - Move objects and refs by archive
@@ -9,10 +9,10 @@ git-bundle - Move objects and refs by archive
SYNOPSIS
--------
[verse]
'git-bundle' create <file> <git-rev-list args>
'git-bundle' verify <file>
'git-bundle' list-heads <file> [refname...]
'git-bundle' unbundle <file> [refname...]
'git bundle' create <file> <git-rev-list args>
'git bundle' verify <file>
'git bundle' list-heads <file> [refname...]
'git bundle' unbundle <file> [refname...]
DESCRIPTION
-----------
@ -116,7 +116,7 @@ We set a tag in R1 (lastR2bundle) after the previous such transport,
@@ -116,7 +116,7 @@ We set a tag in R1 (lastR2bundle) after the previous such transport,
@ -9,8 +9,8 @@ git-cat-file - Provide content or type/size information for repository objects
@@ -9,8 +9,8 @@ git-cat-file - Provide content or type/size information for repository objects
@ -9,7 +9,7 @@ git-checkout-index - Copy files from the index to the working tree
@@ -9,7 +9,7 @@ git-checkout-index - Copy files from the index to the working tree
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,7 +91,7 @@ force-refresh everything in the index, which was not the point. But
since git-checkout-index accepts --stdin it would be faster to use:
Using `git-checkout-index` to "export an entire tree"::
@ -153,10 +153,10 @@ Using `git-checkout-index` to "export an entire tree"::
@@ -153,10 +153,10 @@ Using `git-checkout-index` to "export an entire tree"::
Just read the desired tree into the index, and do:
+
----------------
$ git-checkout-index --prefix=git-export-dir/ -a
$ git checkout-index --prefix=git-export-dir/ -a
----------------
+
`git-checkout-index` will "export" the index into the specified
`git checkout-index` will "export" the index into the specified
directory.
+
The final "/" is important. The exported name is literally just
@ -166,7 +166,7 @@ following example.
@@ -166,7 +166,7 @@ following example.
Export files with a prefix::
+
----------------
$ git-checkout-index --prefix=.merged- Makefile
$ git checkout-index --prefix=.merged- Makefile
----------------
+
This will check out the currently cached copy of `Makefile`
@ -8,8 +8,8 @@ git-checkout - Checkout a branch or paths to the working tree
@@ -8,8 +8,8 @@ git-checkout - Checkout a branch or paths to the working tree
@ -23,7 +23,7 @@ options, which will be passed to `git branch`.
@@ -23,7 +23,7 @@ options, which will be passed to `git branch`.
When <paths> are given, this command does *not* switch
branches. It updates the named paths in the working tree from
the index file (i.e. it runs `git-checkout-index -f -u`), or
the index file (i.e. it runs `git checkout-index -f -u`), or
from a named commit. In
this case, the `-f` and `-b` options are meaningless and giving
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,7 +112,7 @@ current branch and directly point at the commit named by the tag
(`v2.6.18` in the above example).
You can use usual git commands while in this state. You can use
`git-reset --hard $othercommit` to further move around, for
`git reset --hard $othercommit` to further move around, for
example. You can make changes and create a new commit on top of
a detached HEAD. You can even create a merge by using `git
@ -7,7 +7,7 @@ git-cherry-pick - Apply the change introduced by an existing commit
@@ -7,7 +7,7 @@ git-cherry-pick - Apply the change introduced by an existing commit
@ -207,7 +207,7 @@ When recording your own work, the contents of modified files in
@@ -207,7 +207,7 @@ When recording your own work, the contents of modified files in
your working tree are temporarily stored to a staging area
called the "index" with linkgit:git-add[1]. A file can be
reverted back, only in the index but not in the working tree,
to that of the last commit with `git-reset HEAD -- <file>`,
to that of the last commit with `git reset HEAD -- <file>`,
which effectively reverts `git-add` and prevents the changes to
this file from participating in the next commit. After building
the state to be committed incrementally with these commands,
@ -7,7 +7,7 @@ git-count-objects - Count unpacked number of objects and their disk consumption
@@ -7,7 +7,7 @@ git-count-objects - Count unpacked number of objects and their disk consumption
@ -8,7 +8,7 @@ git-cvsexportcommit - Export a single commit to a CVS checkout
@@ -8,7 +8,7 @@ git-cvsexportcommit - Export a single commit to a CVS checkout
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,7 +104,7 @@ Merge pending patches into CVS automatically -- only if you really know what you
@ -9,7 +9,7 @@ git-cvsimport - Salvage your data out of another SCM people love to hate
@@ -9,7 +9,7 @@ git-cvsimport - Salvage your data out of another SCM people love to hate
@ -8,7 +8,7 @@ git-describe - Show the most recent tag that is reachable from a commit
@@ -8,7 +8,7 @@ git-describe - Show the most recent tag that is reachable from a commit
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,7 +94,7 @@ of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
Doing a "git-describe" on a tag-name will just show the tag name:
[torvalds@g5 git]$ git-describe v1.0.4
[torvalds@g5 git]$ git describe v1.0.4
v1.0.4
With --all, the command can use branch heads as references, so
@ -115,13 +115,13 @@ closest tagname without any suffix:
@@ -115,13 +115,13 @@ closest tagname without any suffix:
SEARCH STRATEGY
---------------
For each committish supplied "git describe" will first look for
For each committish supplied "git-describe" will first look for
a tag which tags exactly that commit. Annotated tags will always
be preferred over lightweight tags, and tags with newer dates will
always be preferred over tags with older dates. If an exact match
is found, its name will be output and searching will stop.
If an exact match was not found "git describe" will walk back
If an exact match was not found "git-describe" will walk back
through the commit history to locate an ancestor commit which
has been tagged. The ancestor's tag will be output along with an
@ -8,7 +8,7 @@ git-diff-files - Compares files in the working tree and the index
@@ -8,7 +8,7 @@ git-diff-files - Compares files in the working tree and the index
@ -8,7 +8,7 @@ git-diff-index - Compares content and mode of blobs between the index and reposi
@@ -8,7 +8,7 @@ git-diff-index - Compares content and mode of blobs between the index and reposi
@ -57,20 +57,20 @@ some files in the index and are ready to commit. You want to see exactly
@@ -57,20 +57,20 @@ some files in the index and are ready to commit. You want to see exactly
*what* you are going to commit, without having to write a new tree
object and compare it that way, and to do that, you just do
git-diff-index --cached HEAD
git diff-index --cached HEAD
Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
done an "git-update-index" to make that effective in the index file.
"git-diff-files" wouldn't show anything at all, since the index file
"git diff-files" wouldn't show anything at all, since the index file
matches my working directory. But doing a "git-diff-index" does:
torvalds@ppc970:~/git> git-diff-index --cached HEAD
torvalds@ppc970:~/git> git diff-index --cached HEAD
In fact, "git-diff-index --cached" *should* always be entirely equivalent to
In fact, "git diff-index --cached" *should* always be entirely equivalent to
actually doing a "git-write-tree" and comparing that. Except this one is much
nicer for the case where you just want to check where you are.
@ -98,7 +98,7 @@ show that. So let's say that you have edited `kernel/sched.c`, but
@@ -98,7 +98,7 @@ show that. So let's say that you have edited `kernel/sched.c`, but
have not actually done a "git-update-index" on it yet - there is no
"object" associated with the new state, and you get:
@ -9,7 +9,7 @@ git-diff-tree - Compares the content and mode of blobs found via two tree object
@@ -9,7 +9,7 @@ git-diff-tree - Compares the content and mode of blobs found via two tree object
@ -8,14 +8,14 @@ git-diff - Show changes between commits, commit and working tree, etc
@@ -8,14 +8,14 @@ git-diff - Show changes between commits, commit and working tree, etc
Show changes between two trees, a tree and the working tree, a
tree and the index file, or the index file and the working tree.
'git-diff' [--options] [--] [<path>...]::
'git diff' [--options] [--] [<path>...]::
This form is to view the changes you made relative to
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,14 +27,14 @@ If exactly two paths are given, and at least one is untracked,
compare the two files / directories. This behavior can be
Like `git-push` or `git-fetch`, imports handled by fast-import are safe to
run alongside parallel `git repack -a -d` or `git gc` invocations,
or any other Git operation (including `git prune`, as loose objects
or any other Git operation (including `git-prune`, as loose objects
are never used by fast-import).
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,7 +803,7 @@ Callers may wish to process the output through a tool such as sed to
remove the leading part of the line, for example:
====
frontend | git-fast-import | sed 's/^progress //'
frontend | git fast-import | sed 's/^progress //'
====
Placing a `progress` command immediately after a `checkpoint` will
@ -851,7 +851,7 @@ An example crash:
@@ -851,7 +851,7 @@ An example crash:
M 777 inline bob
END_OF_INPUT
$ git-fast-import <in
$ git fast-import <in
fatal: Corrupt mode: M 777 inline bob
fast-import: dumping crash report to .git/fast_import_crash_8434
@ -8,7 +8,7 @@ git-fetch - Download objects and refs from another repository
@@ -8,7 +8,7 @@ git-fetch - Download objects and refs from another repository
SYNOPSIS
--------
'git-fetch' <options> <repository> <refspec>...
'git fetch' <options> <repository> <refspec>...
DESCRIPTION
@ -18,7 +18,7 @@ the objects necessary to complete them.
@@ -18,7 +18,7 @@ the objects necessary to complete them.
The ref names and their object names of fetched refs are stored
in `.git/FETCH_HEAD`. This information is left for a later merge
operation done by "git merge".
operation done by "git-merge".
When <refspec> stores the fetched result in tracking branches,
the tags that point at these branches are automatically
@ -119,7 +119,7 @@ An example directly producing formatted text. Show the most recent
@@ -119,7 +119,7 @@ An example directly producing formatted text. Show the most recent
@ -135,7 +135,7 @@ demonstrating the use of --shell. List the prefixes of all heads::
@@ -135,7 +135,7 @@ demonstrating the use of --shell. List the prefixes of all heads::
@ -8,7 +8,7 @@ git-fsck-objects - Verifies the connectivity and validity of the objects in the
@@ -8,7 +8,7 @@ git-fsck-objects - Verifies the connectivity and validity of the objects in the
@ -9,7 +9,7 @@ git-fsck - Verifies the connectivity and validity of the objects in the database
@@ -9,7 +9,7 @@ git-fsck - Verifies the connectivity and validity of the objects in the database
@ -79,7 +79,7 @@ that aren't readable from any of the specified head nodes.
@@ -79,7 +79,7 @@ that aren't readable from any of the specified head nodes.
So for example
git-fsck --unreachable HEAD $(cat .git/refs/heads/*)
git fsck --unreachable HEAD $(cat .git/refs/heads/*)
will do quite a _lot_ of verification on the tree. There are a few
extra validity tests to be added (make sure that tree objects are
@ -8,7 +8,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository
@@ -8,7 +8,7 @@ git-gc - Cleanup unnecessary files and optimize the local repository
With this option, `git gc` checks whether any housekeeping is
With this option, `git-gc` checks whether any housekeeping is
required; if not, it exits without performing any work.
Some git commands run `git gc --auto` after performing
operations that could create many loose objects.
@ -89,7 +89,7 @@ how long records of conflicted merge you have not resolved are
@@ -89,7 +89,7 @@ how long records of conflicted merge you have not resolved are
kept. This defaults to 15 days.
The optional configuration variable 'gc.packrefs' determines if
`git gc` runs `git-pack-refs`. This can be set to "nobare" to enable
`git-gc` runs `git-pack-refs`. This can be set to "nobare" to enable
it within all non-bare repos or it can be set to a boolean value.
@ -8,7 +8,7 @@ git-get-tar-commit-id - Extract commit ID from an archive created using git-arch
@@ -8,7 +8,7 @@ git-get-tar-commit-id - Extract commit ID from an archive created using git-arch
@ -8,7 +8,7 @@ git-hash-object - Compute object ID and optionally creates a blob from a file
@@ -8,7 +8,7 @@ git-hash-object - Compute object ID and optionally creates a blob from a file
@ -8,7 +8,7 @@ git-http-fetch - Download from a remote git repository via HTTP
@@ -8,7 +8,7 @@ git-http-fetch - Download from a remote git repository via HTTP
@ -8,7 +8,7 @@ git-http-push - Push objects over HTTP/DAV to another repository
@@ -8,7 +8,7 @@ git-http-push - Push objects over HTTP/DAV to another repository
@ -8,7 +8,7 @@ git-imap-send - Dump a mailbox from stdin into an imap folder
@@ -8,7 +8,7 @@ git-imap-send - Dump a mailbox from stdin into an imap folder
@ -9,8 +9,8 @@ git-index-pack - Build pack index file for an existing packed archive
@@ -9,8 +9,8 @@ git-index-pack - Build pack index file for an existing packed archive
@ -8,7 +8,7 @@ git-init - Create an empty git repository or reinitialize an existing one
@@ -8,7 +8,7 @@ git-init - Create an empty git repository or reinitialize an existing one
@ -8,9 +8,9 @@ git-instaweb - Instantly browse your working repository in gitweb
@@ -8,9 +8,9 @@ git-instaweb - Instantly browse your working repository in gitweb
@ -7,7 +7,7 @@ git-lost-found - Recover lost refs that luckily have not yet been pruned
@@ -7,7 +7,7 @@ git-lost-found - Recover lost refs that luckily have not yet been pruned
@ -9,7 +9,7 @@ git-ls-files - Show information about files in the index and the working tree
@@ -9,7 +9,7 @@ git-ls-files - Show information about files in the index and the working tree
@ -8,7 +8,7 @@ git-mailinfo - Extracts patch and authorship from a single e-mail message
@@ -8,7 +8,7 @@ git-mailinfo - Extracts patch and authorship from a single e-mail message
@ -8,13 +8,13 @@ git-merge-base - Find as good common ancestors as possible for a merge
@@ -8,13 +8,13 @@ git-merge-base - Find as good common ancestors as possible for a merge
SYNOPSIS
--------
'git-merge-base' [--all] <commit> <commit>
'git merge-base' [--all] <commit> <commit>
DESCRIPTION
-----------
"git-merge-base" finds as good a common ancestor as possible between
the two commits. That is, given two commits A and B 'git-merge-base A
the two commits. That is, given two commits A and B 'git merge-base A
B' will output a commit which is reachable from both A and B through
@ -53,7 +53,7 @@ original is first. But the argument order to the 3-way merge program
@@ -53,7 +53,7 @@ original is first. But the argument order to the 3-way merge program
Examples:
torvalds@ppc970:~/merge-test> git-merge-index cat MM
torvalds@ppc970:~/merge-test> git merge-index cat MM
@ -8,7 +8,7 @@ git-merge-tree - Show three-way merge without touching index
@@ -8,7 +8,7 @@ git-merge-tree - Show three-way merge without touching index
@ -60,7 +60,7 @@ A merge is always between the current `HEAD` and one or more
@@ -60,7 +60,7 @@ A merge is always between the current `HEAD` and one or more
commits (usually, branch head or tag), and the index file must
exactly match the
tree of `HEAD` commit (i.e. the contents of the last commit) when
it happens. In other words, `git-diff --cached HEAD` must
it happens. In other words, `git diff --cached HEAD` must
report no changes.
[NOTE]
@ -128,7 +128,7 @@ When there are conflicts, these things happen:
@@ -128,7 +128,7 @@ When there are conflicts, these things happen:
3. For conflicting paths, the index file records up to three
versions; stage1 stores the version from the common ancestor,
stage2 from `HEAD`, and stage3 from the remote branch (you
can inspect the stages with `git-ls-files -u`). The working
can inspect the stages with `git ls-files -u`). The working
tree files have the result of "merge" program; i.e. 3-way
merge result with familiar conflict markers `<<< === >>>`.
@ -144,7 +144,7 @@ After seeing a conflict, you can do two things:
@@ -144,7 +144,7 @@ After seeing a conflict, you can do two things:
up working tree changes made by 2. and 3.; `git-reset` can
be used for this.
* Resolve the conflicts. `git-diff` would report only the
* Resolve the conflicts. `git diff` would report only the
conflicting paths because of the above 2. and 3.. Edit the
working tree files into a desirable shape, `git-add` or `git-rm`
them, to make the index file contain what the merge result
@ -7,7 +7,7 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
@@ -7,7 +7,7 @@ git-mergetool - Run merge conflict resolution tools to resolve merge conflicts
SYNOPSIS
--------
'git-mergetool' [--tool=<tool>] [<file>]...
'git mergetool' [--tool=<tool>] [<file>]...
DESCRIPTION
-----------
@ -17,7 +17,7 @@ merge conflicts. It is typically run after linkgit:git-merge[1].
@@ -17,7 +17,7 @@ merge conflicts. It is typically run after linkgit:git-merge[1].
If one or more <file> parameters are given, the merge tool program will
be run to resolve differences on each file. If no <file> names are
specified, `git mergetool` will run the merge tool program on every file
specified, `git-mergetool` will run the merge tool program on every file
@ -8,7 +8,7 @@ git-mktree - Build a tree-object from ls-tree formatted text
@@ -8,7 +8,7 @@ git-mktree - Build a tree-object from ls-tree formatted text
@ -21,8 +21,8 @@ given will be ignored when checking which packs are required. This makes the
@@ -21,8 +21,8 @@ given will be ignored when checking which packs are required. This makes the
following command useful when wanting to remove packs which contain unreachable
@ -7,7 +7,7 @@ git-pack-refs - Pack heads and tags for efficient repository access
@@ -7,7 +7,7 @@ git-pack-refs - Pack heads and tags for efficient repository access
SYNOPSIS
--------
'git-pack-refs' [--all] [--no-prune]
'git pack-refs' [--all] [--no-prune]
DESCRIPTION
-----------
@ -31,7 +31,7 @@ Subsequent updates to branches always creates new file under
@@ -31,7 +31,7 @@ Subsequent updates to branches always creates new file under
A recommended practice to deal with a repository with too many
refs is to pack its refs with `--all --prune` once, and
occasionally run `git-pack-refs \--prune`. Tags are by
occasionally run `git pack-refs \--prune`. Tags are by
definition stationary and are not expected to change. Branch
heads will be packed with the initial `pack-refs --all`, but
only the currently active branch heads will become unpacked,
@ -8,7 +8,7 @@ git-peek-remote - List the references in a remote repository
@@ -8,7 +8,7 @@ git-peek-remote - List the references in a remote repository
@ -8,7 +8,7 @@ git-prune-packed - Remove extra objects that are already in pack files
@@ -8,7 +8,7 @@ git-prune-packed - Remove extra objects that are already in pack files
@ -22,7 +22,7 @@ objects specified on the command line, and prunes all unpacked
@@ -22,7 +22,7 @@ objects specified on the command line, and prunes all unpacked
objects unreachable from any of these head objects from the object database.
In addition, it
prunes the unpacked objects that are also found in packs by
running `git prune-packed`.
running `git-prune-packed`.
Note that unreachable, packed objects will remain. If this is
not desired, see linkgit:git-repack[1].
@ -53,7 +53,7 @@ borrows from your repository via its
@@ -53,7 +53,7 @@ borrows from your repository via its
@ -8,7 +8,7 @@ git-pull - Fetch from and merge with another repository or a local branch
@@ -8,7 +8,7 @@ git-pull - Fetch from and merge with another repository or a local branch
@ -9,7 +9,7 @@ git-quiltimport - Applies a quilt patchset onto the current branch
@@ -9,7 +9,7 @@ git-quiltimport - Applies a quilt patchset onto the current branch
@ -127,8 +127,8 @@ given pathname, and the contents of the path matches with the tree
@@ -127,8 +127,8 @@ given pathname, and the contents of the path matches with the tree
being read, the stat info from the index is used. (In other words, the
index's stat()s take precedence over the merged tree's).
That means that if you do a `git-read-tree -m <newtree>` followed by a
`git-checkout-index -f -u -a`, the `git-checkout-index` only checks out
That means that if you do a `git read-tree -m <newtree>` followed by a
`git checkout-index -f -u -a`, the `git-checkout-index` only checks out
the stuff that really changed.
This is used to avoid unnecessary false hits when `git-diff-files` is
@ -138,7 +138,7 @@ run after `git-read-tree`.
@@ -138,7 +138,7 @@ run after `git-read-tree`.
Two Tree Merge
~~~~~~~~~~~~~~
Typically, this is invoked as `git-read-tree -m $H $M`, where $H
Typically, this is invoked as `git read-tree -m $H $M`, where $H
is the head commit of the current repository, and $M is the head
of a foreign tree, which is simply ahead of $H (i.e. we are in a
fast forward situation).
@ -151,7 +151,7 @@ the following:
@@ -151,7 +151,7 @@ the following:
2. The user wants to fast-forward to $M.
In this case, the `git-read-tree -m $H $M` command makes sure
In this case, the `git read-tree -m $H $M` command makes sure
that no local change is lost as the result of this "merge".
Here are the "carry forward" rules:
@ -198,13 +198,13 @@ operating under the -u flag.
@@ -198,13 +198,13 @@ operating under the -u flag.
When this form of git-read-tree returns successfully, you can
see what "local changes" you made are carried forward by running
`git-diff-index --cached $M`. Note that this does not
necessarily match `git-diff-index --cached $H` would have
`git diff-index --cached $M`. Note that this does not
necessarily match `git diff-index --cached $H` would have
produced before such a two tree merge. This is because of cases
18 and 19 --- if you already had the changes in $M (e.g. maybe
you picked it up via e-mail in a patch form), `git-diff-index
you picked it up via e-mail in a patch form), `git diff-index
--cached $H` would have told you about the change before this
merge, but it would not show in `git-diff-index --cached $M`
merge, but it would not show in `git diff-index --cached $M`
output after two-tree merge.
@ -219,7 +219,7 @@ starts out at 1.
@@ -219,7 +219,7 @@ starts out at 1.
This means that you can do
----------------
$ git-read-tree -m <tree1> <tree2> <tree3>
$ git read-tree -m <tree1> <tree2> <tree3>
----------------
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,8 +304,8 @@ commit. To illustrate, suppose you start from what has been
committed last to your repository:
----------------
$ JC=`git-rev-parse --verify "HEAD^0"`
$ git-checkout-index -f -u -a $JC
$ JC=`git rev-parse --verify "HEAD^0"`
$ git checkout-index -f -u -a $JC
----------------
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,7 +313,7 @@ you notice that the tip of your "upstream" tree has advanced
since you pulled from him:
----------------
$ git-fetch git://.... linus
$ git fetch git://.... linus
$ LT=`cat .git/FETCH_HEAD`
----------------
@ -323,10 +323,10 @@ added or modified index entries since $JC, and if you haven't,
@@ -323,10 +323,10 @@ added or modified index entries since $JC, and if you haven't,
then does the right thing. So with the following sequence:
@ -8,11 +8,11 @@ git-rebase - Forward-port local commits to the updated upstream head
@@ -8,11 +8,11 @@ git-rebase - Forward-port local commits to the updated upstream head
@ -52,8 +52,8 @@ Assume the following history exists and the current branch is "topic":
@@ -52,8 +52,8 @@ Assume the following history exists and the current branch is "topic":
From this point, the result of either of the following commands:
git-rebase master
git-rebase master topic
git rebase master
git rebase master topic
would be:
@ -68,7 +68,7 @@ followed by `git rebase master`.
@@ -68,7 +68,7 @@ followed by `git rebase master`.
If the upstream branch already contains a change you have made (e.g.,
because you mailed a patch which was applied upstream), then that commit
will be skipped. For example, running `git-rebase master` on the
will be skipped. For example, running `git rebase master` on the
following history (in which A' and A introduce the same set of changes,
but have different committer information):
@ -116,7 +116,7 @@ got merged into more stable 'master' branch, like this:
@@ -116,7 +116,7 @@ got merged into more stable 'master' branch, like this:
We can get this using the following command:
git-rebase --onto master next topic
git rebase --onto master next topic
Another example of --onto option is to rebase part of a
@ -132,7 +132,7 @@ branch. If we have the following situation:
@@ -132,7 +132,7 @@ branch. If we have the following situation:
then the command
git-rebase --onto master topicA topicB
git rebase --onto master topicA topicB
would result in:
@ -155,7 +155,7 @@ the following situation:
@@ -155,7 +155,7 @@ the following situation:
then the command
git-rebase --onto topicA~5 topicA~3 topicA
git rebase --onto topicA~5 topicA~3 topicA
would result in the removal of commits F and G:
@ -168,7 +168,7 @@ part of topicA. Note that the argument to --onto and the <upstream>
@@ -168,7 +168,7 @@ part of topicA. Note that the argument to --onto and the <upstream>
parameter can be any valid commit-ish.
In case of conflict, git-rebase will stop at the first problematic commit
and leave conflict markers in the tree. You can use git diff to locate
and leave conflict markers in the tree. You can use git-diff to locate
the markers (<<<<<<) and make edits to resolve the conflict. For each
file you edit, you need to tell git that the conflict has been resolved,
@ -8,7 +8,7 @@ git-receive-pack - Receive what is pushed into the repository
@@ -8,7 +8,7 @@ git-receive-pack - Receive what is pushed into the repository
SYNOPSIS
--------
'git-receive-pack' <directory>
'git receive-pack' <directory>
DESCRIPTION
-----------
@ -111,10 +111,10 @@ ref listing the commits pushed to the repository:
@@ -111,10 +111,10 @@ ref listing the commits pushed to the repository:
if expr "$oval" : '0*$' >/dev/null
then
echo "Created a new ref, with the following commits:"
git-rev-list --pretty "$nval"
git rev-list --pretty "$nval"
else
echo "New commits:"
git-rev-list --pretty "$nval" "^$oval"
git rev-list --pretty "$nval" "^$oval"
fi |
mail -s "Changes to ref $ref" commit-list@mydomain
done
@ -140,11 +140,11 @@ The exit code from this hook invocation is ignored; the only thing
@@ -140,11 +140,11 @@ The exit code from this hook invocation is ignored; the only thing
left for git-receive-pack to do at that point is to exit itself
anyway.
This hook can be used, for example, to run "git-update-server-info"
This hook can be used, for example, to run "git update-server-info"
if the repository is packed and is served via a dumb transport.
@ -7,7 +7,7 @@ git-rerere - Reuse recorded resolution of conflicted merges
@@ -7,7 +7,7 @@ git-rerere - Reuse recorded resolution of conflicted merges
SYNOPSIS
--------
'git-rerere' [clear|diff|status|gc]
'git rerere' [clear|diff|status|gc]
DESCRIPTION
-----------
@ -198,7 +198,7 @@ you could run `git rebase master topic`, to keep yourself
@@ -198,7 +198,7 @@ you could run `git rebase master topic`, to keep yourself
up-to-date even before your topic is ready to be sent upstream.
This would result in falling back to three-way merge, and it
would conflict the same way the test merge you resolved earlier.
`git-rerere` is run by `git rebase` to help you resolve this
`git-rerere` is run by `git-rebase` to help you resolve this
@ -59,7 +59,7 @@ stop at that point. Their parents are implied. Thus the following
@@ -59,7 +59,7 @@ stop at that point. Their parents are implied. Thus the following
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,8 +70,8 @@ short-hand for "{caret}'<commit1>' '<commit2>'". For example, either of
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,8 +79,8 @@ for merges. The resulting set of commits is the symmetric difference
between the two operands. The following two commands are equivalent:
@ -8,7 +8,7 @@ git-rev-parse - Pick out and massage parameters
@@ -8,7 +8,7 @@ git-rev-parse - Pick out and massage parameters
SYNOPSIS
--------
'git-rev-parse' [ --option ] <args>...
'git rev-parse' [ --option ] <args>...
DESCRIPTION
-----------
@ -296,7 +296,7 @@ reachable from `r1` from the set of commits reachable from
@@ -296,7 +296,7 @@ reachable from `r1` from the set of commits reachable from
A similar notation "`r1\...r2`" is called symmetric difference
of `r1` and `r2` and is defined as
"`r1 r2 --not $(git-merge-base --all r1 r2)`".
"`r1 r2 --not $(git merge-base --all r1 r2)`".
It is the set of commits that are reachable from either one of
`r1` or `r2` but not from both.
@ -384,7 +384,7 @@ bar= some cool option --bar with an argument
@@ -384,7 +384,7 @@ bar= some cool option --bar with an argument
@ -7,12 +7,12 @@ git-rm - Remove files from the working tree and from the index
@@ -7,12 +7,12 @@ git-rm - Remove files from the working tree and from the index
Remove files from the index, or from the working tree and the index.
`git rm` will not remove a file from just your working directory.
`git-rm` will not remove a file from just your working directory.
(There is no option to remove a file only from the work tree
and yet keep it in the index; use `/bin/rm` if you want to do that.)
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,7 +82,7 @@ also remove all of directory `d2`.
EXAMPLES
--------
git-rm Documentation/\\*.txt::
git rm Documentation/\\*.txt::
Removes all `\*.txt` files from the index that are under the
`Documentation` directory and any of its subdirectories.
+
@ -90,7 +90,7 @@ Note that the asterisk `\*` is quoted from the shell in this
@@ -90,7 +90,7 @@ Note that the asterisk `\*` is quoted from the shell in this
example; this lets git, and not the shell, expand the pathnames
of files and subdirectories under the `Documentation/` directory.
git-rm -f git-*.sh::
git rm -f git-*.sh::
Because this example lets the shell expand the asterisk
@ -8,7 +8,7 @@ git-send-pack - Push objects over git protocol to another repository
@@ -8,7 +8,7 @@ git-send-pack - Push objects over git protocol to another repository
@ -144,7 +144,7 @@ For scripting, you can ask it to be quiet with the "--quiet" flag, which
@@ -144,7 +144,7 @@ For scripting, you can ask it to be quiet with the "--quiet" flag, which