Merge branch 'jk/maint-docs' into maint

* jk/maint-docs:
  docs: fix some antique example output
  docs: make sure literal "->" isn't converted to arrow
  docs: update status --porcelain format
  docs: minor grammar fixes to git-status
This commit is contained in:
Junio C Hamano 2011-06-01 14:02:52 -07:00
commit 2dd798469e
4 changed files with 35 additions and 15 deletions

View File

@ -252,7 +252,7 @@ Configuring database backend
'git-cvsserver' uses the Perl DBI module. Please also read
its documentation if changing these variables, especially
about `DBI->connect()`.
about `DBI\->connect()`.
gitcvs.dbname::
Database name. The exact meaning depends on the

View File

@ -96,8 +96,8 @@ 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:
torvalds@ppc970:~/v2.6/linux> git diff-index HEAD
*100644->100664 blob 7476bb......->000000...... kernel/sched.c
torvalds@ppc970:~/v2.6/linux> git diff-index --abbrev HEAD
:100644 100664 7476bb... 000000... kernel/sched.c
i.e., it shows that the tree has changed, and that `kernel/sched.c` has is
not up-to-date and may contain new stuff. The all-zero sha1 means that to

View File

@ -138,8 +138,8 @@ so it can be used to name subdirectories.
An example of normal usage is:
torvalds@ppc970:~/git> git diff-tree 5319e4......
*100664->100664 blob ac348b.......->a01513....... git-fsck-objects.c
torvalds@ppc970:~/git> git diff-tree --abbrev 5319e4
:100664 100664 ac348b... a01513... git-fsck-objects.c
which tells you that the last commit changed just one file (it's from
this one:

View File

@ -32,9 +32,10 @@ OPTIONS
Show the branch and tracking info even in short-format.
--porcelain::
Give the output in a stable, easy-to-parse format for scripts.
Currently this is identical to --short output, but is guaranteed
not to change in the future, making it safe for scripts.
Give the output in an easy-to-parse format for scripts.
This is similar to the short output, but will remain stable
across git versions and regardless of user configuration. See
below for details.
-u[<mode>]::
--untracked-files[=<mode>]::
@ -78,23 +79,27 @@ OUTPUT
The output from this command is designed to be used as a commit
template comment, and all the output lines are prefixed with '#'.
The default, long format, is designed to be human readable,
verbose and descriptive. They are subject to change in any time.
verbose and descriptive. Its contents and format are subject to change
at any time.
The paths mentioned in the output, unlike many other git commands, are
made relative to the current directory if you are working in a
subdirectory (this is on purpose, to help cutting and pasting). See
the status.relativePaths config option below.
In short-format, the status of each path is shown as
Short Format
~~~~~~~~~~~~
In the short-format, the status of each path is shown as
XY PATH1 -> PATH2
where `PATH1` is the path in the `HEAD`, and ` -> PATH2` part is
where `PATH1` is the path in the `HEAD`, and the ` \-> PATH2` part is
shown only when `PATH1` corresponds to a different path in the
index/worktree (i.e. the file is renamed). The 'XY' is a two-letter
status code.
The fields (including the `->`) are separated from each other by a
The fields (including the `\->`) are separated from each other by a
single space. If a filename contains whitespace or other nonprintable
characters, that field will be quoted in the manner of a C string
literal: surrounded by ASCII double quote (34) characters, and with
@ -143,10 +148,25 @@ If -b is used the short-format status is preceded by a line
## branchname tracking info
There is an alternate -z format recommended for machine parsing. In
Porcelain Format
~~~~~~~~~~~~~~~~
The porcelain format is similar to the short format, but is guaranteed
not to change in a backwards-incompatible way between git versions or
based on user configuration. This makes it ideal for parsing by scripts.
The description of the short format above also describes the porcelain
format, with a few exceptions:
1. The user's color.status configuration is not respected; color will
always be off.
2. The user's status.relativePaths configuration is not respected; paths
shown will always be relative to the repository root.
There is also an alternate -z format recommended for machine parsing. In
that format, the status field is the same, but some other things
change. First, the '->' is omitted from rename entries and the field
order is reversed (e.g 'from -> to' becomes 'to from'). Second, a NUL
change. First, the '\->' is omitted from rename entries and the field
order is reversed (e.g 'from \-> to' becomes 'to from'). Second, a NUL
(ASCII 0) follows each filename, replacing space as a field separator
and the terminating newline (but a space still separates the status
field from the first filename). Third, filenames containing special