Commit b1889c36 authored by Jonathan Nieder's avatar Jonathan Nieder Committed by Junio C Hamano

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: default avatarJonathan Nieder <[email protected]>
Signed-off-by: default avatarJunio C Hamano <[email protected]>
parent 46e56e81
......@@ -8,7 +8,7 @@ git-add - Add file contents to the index
SYNOPSIS
--------
[verse]
'git-add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
[--update | -u] [--refresh] [--ignore-errors] [--]
<filepattern>...
......
......@@ -9,11 +9,11 @@ git-am - Apply a series of patches from a mailbox
SYNOPSIS
--------
[verse]
'git-am' [--signoff] [--keep] [--utf8 | --no-utf8]
'git am' [--signoff] [--keep] [--utf8 | --no-utf8]
[--3way] [--interactive] [--binary]
[--whitespace=<option>] [-C<n>] [-p<n>]
<mbox>|<Maildir>...
'git-am' [--skip | --resolved]
'git am' [--skip | --resolved]
DESCRIPTION
-----------
......
......@@ -7,7 +7,7 @@ git-annotate - Annotate file lines with commit info
SYNOPSIS
--------
git-annotate [options] file [revision]
git annotate [options] file [revision]
DESCRIPTION
-----------
......
......@@ -9,7 +9,7 @@ git-apply - Apply a patch on a git index file and a working tree
SYNOPSIS
--------
[verse]
'git-apply' [--stat] [--numstat] [--summary] [--check] [--index]
'git apply' [--stat] [--numstat] [--summary] [--check] [--index]
[--apply] [--no-add] [--build-fake-ancestor <file>] [-R | --reverse]
[--allow-binary-replacement | --binary] [--reject] [-z]
[-pNUM] [-CNUM] [--inaccurate-eof] [--recount] [--cached]
......
......@@ -9,7 +9,7 @@ git-archimport - Import an Arch repository into git
SYNOPSIS
--------
[verse]
'git-archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
'git archimport' [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
<archive/branch>[:<git-branch>] ...
DESCRIPTION
......
......@@ -9,7 +9,7 @@ git-archive - Create an archive of files from a named tree
SYNOPSIS
--------
[verse]
'git-archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
'git archive' --format=<fmt> [--list] [--prefix=<prefix>/] [<extra>]
[--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
[path...]
......
......@@ -26,7 +26,7 @@ on the subcommand:
git bisect log
git bisect run <cmd>...
This command uses 'git-rev-list --bisect' option to help drive the
This command uses 'git rev-list --bisect' option to help drive the
binary search process to find which change introduced a bug, given an
old "good" commit object name and a later "bad" commit object name.
......
......@@ -8,7 +8,7 @@ git-blame - Show what revision and author last modified each line of a file
SYNOPSIS
--------
[verse]
'git-blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
[-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
[<rev> | --contents <file>] [--] <file>
......
......@@ -8,12 +8,12 @@ git-branch - List, create, or delete branches
SYNOPSIS
--------
[verse]
'git-branch' [--color | --no-color] [-r | -a] [--merged | --no-merged]
'git branch' [--color | --no-color] [-r | -a] [--merged | --no-merged]
[-v [--abbrev=<length> | --no-abbrev]]
[--contains <commit>]
'git-branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git-branch' (-m | -M) [<oldbranch>] <newbranch>
'git-branch' (-d | -D) [-r] <branchname>...
'git branch' [--track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
'git branch' (-d | -D) [-r] <branchname>...
DESCRIPTION
-----------
......
......@@ -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,
and move it afterwards to help build the bundle.
------------
$ git-bundle create mybundle master ^lastR2bundle
$ git bundle create mybundle master ^lastR2bundle
$ git tag -f lastR2bundle master
------------
......@@ -141,8 +141,8 @@ $ git bundle create mybundle master -n 10
Then you move mybundle from A to B, and in R2 on B:
------------
$ git-bundle verify mybundle
$ git-fetch mybundle master:localRef
$ git bundle verify mybundle
$ git fetch mybundle master:localRef
------------
With something like this in the config in R2:
......
......@@ -9,8 +9,8 @@ git-cat-file - Provide content or type/size information for repository objects
SYNOPSIS
--------
[verse]
'git-cat-file' [-t | -s | -e | -p | <type>] <object>
'git-cat-file' [--batch | --batch-check] < <list-of-objects>
'git cat-file' [-t | -s | -e | -p | <type>] <object>
'git cat-file' [--batch | --batch-check] < <list-of-objects>
DESCRIPTION
-----------
......
......@@ -8,7 +8,7 @@ git-check-attr - Display gitattributes information.
SYNOPSIS
--------
'git-check-attr' attr... [--] pathname...
'git check-attr' attr... [--] pathname...
DESCRIPTION
-----------
......
......@@ -7,7 +7,7 @@ git-check-ref-format - Make sure ref name is well formed
SYNOPSIS
--------
'git-check-ref-format' <refname>
'git check-ref-format' <refname>
DESCRIPTION
-----------
......@@ -47,7 +47,7 @@ refname expressions (see linkgit:git-rev-parse[1]). Namely:
. colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
value and store it in dstref" in fetch and push operations.
It may also be used to select a specific object such as with
linkgit:git-cat-file[1] "git-cat-file blob v1.3.3:refs.c".
linkgit:git-cat-file[1] "git cat-file blob v1.3.3:refs.c".
GIT
......
......@@ -9,7 +9,7 @@ git-checkout-index - Copy files from the index to the working tree
SYNOPSIS
--------
[verse]
'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
'git checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
[--stage=<number>|all]
[--temp]
[-z] [--stdin]
......@@ -73,16 +73,16 @@ OPTIONS
The order of the flags used to matter, but not anymore.
Just doing `git-checkout-index` does nothing. You probably meant
`git-checkout-index -a`. And if you want to force it, you want
`git-checkout-index -f -a`.
Just doing `git checkout-index` does nothing. You probably meant
`git checkout-index -a`. And if you want to force it, you want
`git checkout-index -f -a`.
Intuitiveness is not the goal here. Repeatability is. The reason for
the "no arguments means no work" behavior is that from scripts you are
supposed to be able to do:
----------------
$ find . -name '*.h' -print0 | xargs -0 git-checkout-index -f --
$ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
----------------
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
since git-checkout-index accepts --stdin it would be faster to use:
----------------
$ find . -name '*.h' -print0 | git-checkout-index -f -z --stdin
$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
----------------
The `--` is just a good idea when you know the rest will be filenames;
......@@ -144,7 +144,7 @@ EXAMPLES
To update and refresh only the files already checked out::
+
----------------
$ git-checkout-index -n -f -a && git-update-index --ignore-missing --refresh
$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
----------------
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.
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
SYNOPSIS
--------
[verse]
'git-checkout' [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>]
'git-checkout' [<tree-ish>] <paths>...
'git checkout' [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>]
'git checkout' [<tree-ish>] <paths>...
DESCRIPTION
-----------
......@@ -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
(`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
merge $othercommit`.
......
......@@ -7,7 +7,7 @@ git-cherry-pick - Apply the change introduced by an existing commit
SYNOPSIS
--------
'git-cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] <commit>
'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] <commit>
DESCRIPTION
-----------
......
......@@ -7,7 +7,7 @@ git-cherry - Find commits not merged upstream
SYNOPSIS
--------
'git-cherry' [-v] <upstream> [<head>] [<limit>]
'git cherry' [-v] <upstream> [<head>] [<limit>]
DESCRIPTION
-----------
......
......@@ -8,7 +8,7 @@ git-clean - Remove untracked files from the working tree
SYNOPSIS
--------
[verse]
'git-clean' [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...
'git clean' [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>...
DESCRIPTION
-----------
......
......@@ -9,7 +9,7 @@ git-clone - Clone a repository into a new directory
SYNOPSIS
--------
[verse]
'git-clone' [--template=<template_directory>]
'git clone' [--template=<template_directory>]
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
[--depth <depth>] [--] <repository> [<directory>]
......
......@@ -8,7 +8,7 @@ git-commit-tree - Create a new commit object
SYNOPSIS
--------
'git-commit-tree' <tree> [-p <parent commit>]\* < changelog
'git commit-tree' <tree> [-p <parent commit>]\* < changelog
DESCRIPTION
-----------
......
......@@ -8,7 +8,7 @@ git-commit - Record changes to the repository
SYNOPSIS
--------
[verse]
'git-commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend]
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend]
[(-c | -C) <commit>] [-F <file> | -m <msg>]
[--allow-empty] [--no-verify] [-e] [--author=<author>]
[--cleanup=<mode>] [--] [[-i | -o ]<file>...]
......@@ -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,
......
......@@ -9,19 +9,19 @@ git-config - Get and set repository or global options
SYNOPSIS
--------
[verse]
'git-config' [<file-option>] [type] [-z|--null] name [value [value_regex]]
'git-config' [<file-option>] [type] --add name value
'git-config' [<file-option>] [type] --replace-all name [value [value_regex]]
'git-config' [<file-option>] [type] [-z|--null] --get name [value_regex]
'git-config' [<file-option>] [type] [-z|--null] --get-all name [value_regex]
'git-config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex]
'git-config' [<file-option>] --unset name [value_regex]
'git-config' [<file-option>] --unset-all name [value_regex]
'git-config' [<file-option>] --rename-section old_name new_name
'git-config' [<file-option>] --remove-section name
'git-config' [<file-option>] [-z|--null] -l | --list
'git-config' [<file-option>] --get-color name [default]
'git-config' [<file-option>] --get-colorbool name [stdout-is-tty]
'git config' [<file-option>] [type] [-z|--null] name [value [value_regex]]
'git config' [<file-option>] [type] --add name value
'git config' [<file-option>] [type] --replace-all name [value [value_regex]]
'git config' [<file-option>] [type] [-z|--null] --get name [value_regex]
'git config' [<file-option>] [type] [-z|--null] --get-all name [value_regex]
'git config' [<file-option>] [type] [-z|--null] --get-regexp name_regex [value_regex]
'git config' [<file-option>] --unset name [value_regex]
'git config' [<file-option>] --unset-all name [value_regex]
'git config' [<file-option>] --rename-section old_name new_name
'git config' [<file-option>] --remove-section name
'git config' [<file-option>] [-z|--null] -l | --list
'git config' [<file-option>] --get-color name [default]
'git config' [<file-option>] --get-colorbool name [stdout-is-tty]
DESCRIPTION
-----------
......
......@@ -7,7 +7,7 @@ git-count-objects - Count unpacked number of objects and their disk consumption
SYNOPSIS
--------
'git-count-objects' [-v]
'git count-objects' [-v]
DESCRIPTION
-----------
......@@ -22,7 +22,7 @@ OPTIONS
In addition to the number of loose objects and disk
space consumed, it reports the number of in-pack
objects, number of packs, and number of objects that can be
removed by running `git-prune-packed`.
removed by running `git prune-packed`.
Author
......
......@@ -8,7 +8,7 @@ git-cvsexportcommit - Export a single commit to a CVS checkout
SYNOPSIS
--------
'git-cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
'git cvsexportcommit' [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot] [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
DESCRIPTION
......@@ -89,14 +89,14 @@ Merge one patch into CVS::
------------
$ export GIT_DIR=~/project/.git
$ cd ~/project_cvs_checkout
$ git-cvsexportcommit -v <commit-sha1>
$ git cvsexportcommit -v <commit-sha1>
$ cvs commit -F .msg <files>
------------
Merge one patch into CVS (-c and -w options). The working directory is within the Git Repo::
+
------------
$ git-cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
$ git cvsexportcommit -v -c -w ~/project_cvs_checkout <commit-sha1>
------------
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
------------
$ export GIT_DIR=~/project/.git
$ cd ~/project_cvs_checkout
$ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit -c -p -v
$ git cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git cvsexportcommit -c -p -v
------------
Author
......
......@@ -9,7 +9,7 @@ git-cvsimport - Salvage your data out of another SCM people love to hate
SYNOPSIS
--------
[verse]
'git-cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
'git cvsimport' [-o <branch-for-HEAD>] [-h] [-v] [-d <CVSROOT>]
[-A <author-conv-file>] [-p <options-for-cvsps>] [-P <file>]
[-C <git_repository>] [-z <fuzz>] [-i] [-k] [-u] [-s <subst>]
[-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>]
......@@ -27,7 +27,7 @@ At least version 2.1 is required.
You should *never* do any work of your own on the branches that are
created by git-cvsimport. By default initial import will create and populate a
"master" branch from the CVS repository's main branch which you're free
to work with; after that, you need to 'git merge' incremental imports, or
to work with; after that, you need to 'git-merge' incremental imports, or
any CVS branches, yourself. It is advisable to specify a named remote via
-r to separate and protect the incoming branches.
......
......@@ -22,7 +22,7 @@ cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
Usage:
[verse]
'git-cvsserver' [options] [pserver|server] [<directory> ...]
'git cvsserver' [options] [pserver|server] [<directory> ...]
OPTIONS
-------
......
......@@ -8,7 +8,7 @@ git-daemon - A really simple server for git repositories
SYNOPSIS
--------
[verse]
'git-daemon' [--verbose] [--syslog] [--export-all]
'git daemon' [--verbose] [--syslog] [--export-all]
[--timeout=n] [--init-timeout=n] [--strict-paths]
[--base-path=path] [--user-path | --user-path=path]
[--interpolated-path=pathtemplate]
......
......@@ -8,7 +8,7 @@ git-describe - Show the most recent tag that is reachable from a commit
SYNOPSIS
--------
'git-describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
DESCRIPTION
-----------
......@@ -78,7 +78,7 @@ EXAMPLES
With something like git.git current tree, I get:
[[email protected] git]$ git-describe parent
[[email protected] git]$ git describe parent
v1.0.4-14-g2414721
i.e. the current head of my "parent" branch is based on v1.0.4,
......@@ -94,7 +94,7 @@ of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
Doing a "git-describe" on a tag-name will just show the tag name:
[[email protected] git]$ git-describe v1.0.4
[[email protected] 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:
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
abbreviation of the input committish's SHA1.
......
......@@ -8,7 +8,7 @@ git-diff-files - Compares files in the working tree and the index
SYNOPSIS
--------
'git-diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...]
'git diff-files' [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>...]
DESCRIPTION
-----------
......
......@@ -8,7 +8,7 @@ git-diff-index - Compares content and mode of blobs between the index and reposi
SYNOPSIS
--------
'git-diff-index' [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
'git diff-index' [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
DESCRIPTION
-----------
......@@ -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:
[email protected]:~/git> git-diff-index --cached HEAD
[email protected]:~/git> git diff-index --cached HEAD
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
You can see easily that the above is a rename.
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
have not actually done a "git-update-index" on it yet - there is no
"object" associated with the new state, and you get:
[email protected]:~/v2.6/linux> git-diff-index HEAD
[email protected]:~/v2.6/linux> git diff-index HEAD
*100644->100664 blob 7476bb......->000000...... kernel/sched.c
i.e., it shows that the tree has changed, and that `kernel/sched.c` has is
......
......@@ -9,7 +9,7 @@ git-diff-tree - Compares the content and mode of blobs found via two tree object
SYNOPSIS
--------
[verse]
'git-diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
'git diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
[-t] [-r] [-c | --cc] [--root] [<common diff options>]
<tree-ish> [<tree-ish>] [<path>...]
......@@ -112,13 +112,13 @@ Limiting Output
If you're only interested in differences in a subset of files, for
example some architecture-specific files, you might do:
git-diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64
git diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64
and it will only show you what changed in those two directories.
Or if you are searching for what changed in just `kernel/sched.c`, just do
git-diff-tree -r <tree-ish> <tree-ish> kernel/sched.c
git diff-tree -r <tree-ish> <tree-ish> kernel/sched.c
and it will ignore all differences to other files.
......@@ -129,7 +129,7 @@ so it can be used to name subdirectories.
An example of normal usage is:
[email protected]:~/git> git-diff-tree 5319e4......
[email protected]:~/git> git diff-tree 5319e4......
*100664->100664 blob ac348b.......->a01513....... git-fsck-objects.c
which tells you that the last commit changed just one file (it's from
......
......@@ -8,14 +8,14 @@ git-diff - Show changes between commits, commit and working tree, etc
SYNOPSIS
--------
'git-diff' [<common diff options>] <commit>{0,2} [--] [<path>...]
'git diff' [<common diff options>] <commit>{0,2} [--] [<path>...]
DESCRIPTION
-----------
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,
compare the two files / directories. This behavior can be
forced by --no-index.
'git-diff' [--options] --cached [<commit>] [--] [<path>...]::
'git diff' [--options] --cached [<commit>] [--] [<path>...]::
This form is to view the changes you staged for the next
commit relative to the named <commit>. Typically you
would want comparison with the latest commit, so if you
do not give <commit>, it defaults to HEAD.
'git-diff' [--options] <commit> [--] [<path>...]::
'git diff' [--options] <commit> [--] [<path>...]::
This form is to view the changes you have in your
working tree relative to the named <commit>. You can
......@@ -42,23 +42,23 @@ forced by --no-index.
branch name to compare with the tip of a different
branch.
'git-diff' [--options] <commit> <commit> [--] [<path>...]::
'git diff' [--options] <commit> <commit> [--] [<path>...]::
This is to view the changes between two arbitrary
<commit>.
'git-diff' [--options] <commit>..<commit> [--] [<path>...]::
'git diff' [--options] <commit>..<commit> [--] [<path>...]::
This is synonymous to the previous form. If <commit> on
one side is omitted, it will have the same effect as
using HEAD instead.
'git-diff' [--options] <commit>\...<commit> [--] [<path>...]::
'git diff' [--options] <commit>\...<commit> [--] [<path>...]::
This form is to view the changes on the branch containing
and up to the second <commit>, starting at a common ancestor
of both <commit>. "git-diff A\...B" is equivalent to
"git-diff $(git-merge-base A B) B". You can omit any one
of both <commit>. "git diff A\...B" is equivalent to
"git diff $(git-merge-base A B) B". You can omit any one
of <commit>, which has the same effect as using HEAD instead.
Just in case if you are doing something exotic, it should be
......
......@@ -8,7 +8,7 @@ git-fast-export - Git data exporter
SYNOPSIS
--------
'git-fast-export [options]' | 'git-fast-import'
'git fast-export [options]' | 'git fast-import'
DESCRIPTION
-----------
......
......@@ -8,7 +8,7 @@ git-fast-import - Backend for fast Git data importers
SYNOPSIS
--------
frontend | 'git-fast-import' [options]
frontend | 'git fast-import' [options]
DESCRIPTION
-----------
......@@ -126,7 +126,7 @@ Parallel Operation
------------------
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
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:
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-pack - Receive missing objects from another repository
SYNOPSIS
--------
'git-fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>...]
'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>...]
DESCRIPTION
-----------
......
......@@ -8,7 +8,7 @@ git-fetch - Download objects and refs from another repository