oneway_diff: handle removed sparse directories
[alt-git.git] / Documentation / git-status.txt
blob54a4b29b473cc4e928b484286b01b337c9b25bdd
1 git-status(1)
2 =============
4 NAME
5 ----
6 git-status - Show the working tree status
9 SYNOPSIS
10 --------
11 [verse]
12 'git status' [<options>...] [--] [<pathspec>...]
14 DESCRIPTION
15 -----------
16 Displays paths that have differences between the index file and the
17 current HEAD commit, paths that have differences between the working
18 tree and the index file, and paths in the working tree that are not
19 tracked by Git (and are not ignored by linkgit:gitignore[5]). The first
20 are what you _would_ commit by running `git commit`; the second and
21 third are what you _could_ commit by running 'git add' before running
22 `git commit`.
24 OPTIONS
25 -------
27 -s::
28 --short::
29         Give the output in the short-format.
31 -b::
32 --branch::
33         Show the branch and tracking info even in short-format.
35 --show-stash::
36         Show the number of entries currently stashed away.
38 --porcelain[=<version>]::
39         Give the output in an easy-to-parse format for scripts.
40         This is similar to the short output, but will remain stable
41         across Git versions and regardless of user configuration. See
42         below for details.
44 The version parameter is used to specify the format version.
45 This is optional and defaults to the original version 'v1' format.
47 --long::
48         Give the output in the long-format. This is the default.
50 -v::
51 --verbose::
52         In addition to the names of files that have been changed, also
53         show the textual changes that are staged to be committed
54         (i.e., like the output of `git diff --cached`). If `-v` is specified
55         twice, then also show the changes in the working tree that
56         have not yet been staged (i.e., like the output of `git diff`).
58 -u[<mode>]::
59 --untracked-files[=<mode>]::
60         Show untracked files.
63 The mode parameter is used to specify the handling of untracked files.
64 It is optional: it defaults to 'all', and if specified, it must be
65 stuck to the option (e.g. `-uno`, but not `-u no`).
67 The possible options are:
69         - 'no'     - Show no untracked files.
70         - 'normal' - Shows untracked files and directories.
71         - 'all'    - Also shows individual files in untracked directories.
73 When `-u` option is not used, untracked files and directories are
74 shown (i.e. the same as specifying `normal`), to help you avoid
75 forgetting to add newly created files.  Because it takes extra work
76 to find untracked files in the filesystem, this mode may take some
77 time in a large working tree.
78 Consider enabling untracked cache and split index if supported (see
79 `git update-index --untracked-cache` and `git update-index
80 --split-index`), Otherwise you can use `no` to have `git status`
81 return more quickly without showing untracked files.
83 The default can be changed using the status.showUntrackedFiles
84 configuration variable documented in linkgit:git-config[1].
87 --ignore-submodules[=<when>]::
88         Ignore changes to submodules when looking for changes. <when> can be
89         either "none", "untracked", "dirty" or "all", which is the default.
90         Using "none" will consider the submodule modified when it either contains
91         untracked or modified files or its HEAD differs from the commit recorded
92         in the superproject and can be used to override any settings of the
93         'ignore' option in linkgit:git-config[1] or linkgit:gitmodules[5]. When
94         "untracked" is used submodules are not considered dirty when they only
95         contain untracked content (but they are still scanned for modified
96         content). Using "dirty" ignores all changes to the work tree of submodules,
97         only changes to the commits stored in the superproject are shown (this was
98         the behavior before 1.7.0). Using "all" hides all changes to submodules
99         (and suppresses the output of submodule summaries when the config option
100         `status.submoduleSummary` is set).
102 --ignored[=<mode>]::
103         Show ignored files as well.
106 The mode parameter is used to specify the handling of ignored files.
107 It is optional: it defaults to 'traditional'.
109 The possible options are:
111         - 'traditional' - Shows ignored files and directories, unless
112                           --untracked-files=all is specified, in which case
113                           individual files in ignored directories are
114                           displayed.
115         - 'no'          - Show no ignored files.
116         - 'matching'    - Shows ignored files and directories matching an
117                           ignore pattern.
119 When 'matching' mode is specified, paths that explicitly match an
120 ignored pattern are shown. If a directory matches an ignore pattern,
121 then it is shown, but not paths contained in the ignored directory. If
122 a directory does not match an ignore pattern, but all contents are
123 ignored, then the directory is not shown, but all contents are shown.
126 -z::
127         Terminate entries with NUL, instead of LF.  This implies
128         the `--porcelain=v1` output format if no other format is given.
130 --column[=<options>]::
131 --no-column::
132         Display untracked files in columns. See configuration variable
133         `column.status` for option syntax. `--column` and `--no-column`
134         without options are equivalent to 'always' and 'never'
135         respectively.
137 --ahead-behind::
138 --no-ahead-behind::
139         Display or do not display detailed ahead/behind counts for the
140         branch relative to its upstream branch.  Defaults to true.
142 --renames::
143 --no-renames::
144         Turn on/off rename detection regardless of user configuration.
145         See also linkgit:git-diff[1] `--no-renames`.
147 --find-renames[=<n>]::
148         Turn on rename detection, optionally setting the similarity
149         threshold.
150         See also linkgit:git-diff[1] `--find-renames`.
152 <pathspec>...::
153         See the 'pathspec' entry in linkgit:gitglossary[7].
155 OUTPUT
156 ------
157 The output from this command is designed to be used as a commit
158 template comment.
159 The default, long format, is designed to be human readable,
160 verbose and descriptive.  Its contents and format are subject to change
161 at any time.
163 The paths mentioned in the output, unlike many other Git commands, are
164 made relative to the current directory if you are working in a
165 subdirectory (this is on purpose, to help cutting and pasting). See
166 the status.relativePaths config option below.
168 Short Format
169 ~~~~~~~~~~~~
171 In the short-format, the status of each path is shown as one of these
172 forms
174         XY PATH
175         XY ORIG_PATH -> PATH
177 where `ORIG_PATH` is where the renamed/copied contents came
178 from. `ORIG_PATH` is only shown when the entry is renamed or
179 copied. The `XY` is a two-letter status code.
181 The fields (including the `->`) are separated from each other by a
182 single space. If a filename contains whitespace or other nonprintable
183 characters, that field will be quoted in the manner of a C string
184 literal: surrounded by ASCII double quote (34) characters, and with
185 interior special characters backslash-escaped.
187 There are three different types of states that are shown using this format, and
188 each one uses the `XY` syntax differently:
190 * When a merge is occurring and the merge was successful, or outside of a merge
191         situation, `X` shows the status of the index and `Y` shows the status of the
192         working tree.
193 * When a merge conflict has occurred and has not yet been resolved, `X` and `Y`
194         show the state introduced by each head of the merge, relative to the common
195         ancestor. These paths are said to be _unmerged_.
196 * When a path is untracked, `X` and `Y` are always the same, since they are
197         unknown to the index. `??` is used for untracked paths. Ignored files are
198         not listed unless `--ignored` is used; if it is, ignored files are indicated
199         by `!!`.
201 Note that the term _merge_ here also includes rebases using the default
202 `--merge` strategy, cherry-picks, and anything else using the merge machinery.
204 In the following table, these three classes are shown in separate sections, and
205 these characters are used for `X` and `Y` fields for the first two sections that
206 show tracked paths:
208 * ' ' = unmodified
209 * 'M' = modified
210 * 'T' = file type changed (regular file, symbolic link or submodule)
211 * 'A' = added
212 * 'D' = deleted
213 * 'R' = renamed
214 * 'C' = copied (if config option status.renames is set to "copies")
215 * 'U' = updated but unmerged
217 ....
218 X          Y     Meaning
219 -------------------------------------------------
220          [AMD]   not updated
221 M        [ MTD]  updated in index
222 T        [ MTD]  type changed in index
223 A        [ MTD]  added to index
224 D                deleted from index
225 R        [ MTD]  renamed in index
226 C        [ MTD]  copied in index
227 [MTARC]          index and work tree matches
228 [ MTARC]    M    work tree changed since index
229 [ MTARC]    T    type changed in work tree since index
230 [ MTARC]    D    deleted in work tree
231             R    renamed in work tree
232             C    copied in work tree
233 -------------------------------------------------
234 D           D    unmerged, both deleted
235 A           U    unmerged, added by us
236 U           D    unmerged, deleted by them
237 U           A    unmerged, added by them
238 D           U    unmerged, deleted by us
239 A           A    unmerged, both added
240 U           U    unmerged, both modified
241 -------------------------------------------------
242 ?           ?    untracked
243 !           !    ignored
244 -------------------------------------------------
245 ....
247 Submodules have more state and instead report
248                 M    the submodule has a different HEAD than
249                      recorded in the index
250                 m    the submodule has modified content
251                 ?    the submodule has untracked files
252 since modified content or untracked files in a submodule cannot be added
253 via `git add` in the superproject to prepare a commit.
255 'm' and '?' are applied recursively. For example if a nested submodule
256 in a submodule contains an untracked file, this is reported as '?' as well.
258 If -b is used the short-format status is preceded by a line
260     ## branchname tracking info
262 Porcelain Format Version 1
263 ~~~~~~~~~~~~~~~~~~~~~~~~~~
265 Version 1 porcelain format is similar to the short format, but is guaranteed
266 not to change in a backwards-incompatible way between Git versions or
267 based on user configuration. This makes it ideal for parsing by scripts.
268 The description of the short format above also describes the porcelain
269 format, with a few exceptions:
271 1. The user's color.status configuration is not respected; color will
272    always be off.
274 2. The user's status.relativePaths configuration is not respected; paths
275    shown will always be relative to the repository root.
277 There is also an alternate -z format recommended for machine parsing. In
278 that format, the status field is the same, but some other things
279 change.  First, the '\->' is omitted from rename entries and the field
280 order is reversed (e.g 'from \-> to' becomes 'to from'). Second, a NUL
281 (ASCII 0) follows each filename, replacing space as a field separator
282 and the terminating newline (but a space still separates the status
283 field from the first filename).  Third, filenames containing special
284 characters are not specially formatted; no quoting or
285 backslash-escaping is performed.
287 Any submodule changes are reported as modified `M` instead of `m` or single `?`.
289 Porcelain Format Version 2
290 ~~~~~~~~~~~~~~~~~~~~~~~~~~
292 Version 2 format adds more detailed information about the state of
293 the worktree and changed items.  Version 2 also defines an extensible
294 set of easy to parse optional headers.
296 Header lines start with "#" and are added in response to specific
297 command line arguments.  Parsers should ignore headers they
298 don't recognize.
300 Branch Headers
301 ^^^^^^^^^^^^^^
303 If `--branch` is given, a series of header lines are printed with
304 information about the current branch.
306 ....
307 Line                                     Notes
308 ------------------------------------------------------------
309 # branch.oid <commit> | (initial)        Current commit.
310 # branch.head <branch> | (detached)      Current branch.
311 # branch.upstream <upstream_branch>      If upstream is set.
312 # branch.ab +<ahead> -<behind>           If upstream is set and
313                                          the commit is present.
314 ------------------------------------------------------------
315 ....
317 Stash Information
318 ^^^^^^^^^^^^^^^^^
320 If `--show-stash` is given, one line is printed showing the number of stash
321 entries if non-zero:
323     # stash <N>
325 Changed Tracked Entries
326 ^^^^^^^^^^^^^^^^^^^^^^^
328 Following the headers, a series of lines are printed for tracked
329 entries.  One of three different line formats may be used to describe
330 an entry depending on the type of change.  Tracked entries are printed
331 in an undefined order; parsers should allow for a mixture of the 3
332 line types in any order.
334 Ordinary changed entries have the following format:
336     1 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <path>
338 Renamed or copied entries have the following format:
340     2 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <X><score> <path><sep><origPath>
342 ....
343 Field       Meaning
344 --------------------------------------------------------
345 <XY>        A 2 character field containing the staged and
346             unstaged XY values described in the short format,
347             with unchanged indicated by a "." rather than
348             a space.
349 <sub>       A 4 character field describing the submodule state.
350             "N..." when the entry is not a submodule.
351             "S<c><m><u>" when the entry is a submodule.
352             <c> is "C" if the commit changed; otherwise ".".
353             <m> is "M" if it has tracked changes; otherwise ".".
354             <u> is "U" if there are untracked changes; otherwise ".".
355 <mH>        The octal file mode in HEAD.
356 <mI>        The octal file mode in the index.
357 <mW>        The octal file mode in the worktree.
358 <hH>        The object name in HEAD.
359 <hI>        The object name in the index.
360 <X><score>  The rename or copy score (denoting the percentage
361             of similarity between the source and target of the
362             move or copy). For example "R100" or "C75".
363 <path>      The pathname.  In a renamed/copied entry, this
364             is the target path.
365 <sep>       When the `-z` option is used, the 2 pathnames are separated
366             with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
367             byte separates them.
368 <origPath>  The pathname in the commit at HEAD or in the index.
369             This is only present in a renamed/copied entry, and
370             tells where the renamed/copied contents came from.
371 --------------------------------------------------------
372 ....
374 Unmerged entries have the following format; the first character is
375 a "u" to distinguish from ordinary changed entries.
377     u <XY> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <path>
379 ....
380 Field       Meaning
381 --------------------------------------------------------
382 <XY>        A 2 character field describing the conflict type
383             as described in the short format.
384 <sub>       A 4 character field describing the submodule state
385             as described above.
386 <m1>        The octal file mode in stage 1.
387 <m2>        The octal file mode in stage 2.
388 <m3>        The octal file mode in stage 3.
389 <mW>        The octal file mode in the worktree.
390 <h1>        The object name in stage 1.
391 <h2>        The object name in stage 2.
392 <h3>        The object name in stage 3.
393 <path>      The pathname.
394 --------------------------------------------------------
395 ....
397 Other Items
398 ^^^^^^^^^^^
400 Following the tracked entries (and if requested), a series of
401 lines will be printed for untracked and then ignored items
402 found in the worktree.
404 Untracked items have the following format:
406     ? <path>
408 Ignored items have the following format:
410     ! <path>
412 Pathname Format Notes and -z
413 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
415 When the `-z` option is given, pathnames are printed as is and
416 without any quoting and lines are terminated with a NUL (ASCII 0x00)
417 byte.
419 Without the `-z` option, pathnames with "unusual" characters are
420 quoted as explained for the configuration variable `core.quotePath`
421 (see linkgit:git-config[1]).
424 CONFIGURATION
425 -------------
427 The command honors `color.status` (or `status.color` -- they
428 mean the same thing and the latter is kept for backward
429 compatibility) and `color.status.<slot>` configuration variables
430 to colorize its output.
432 If the config variable `status.relativePaths` is set to false, then all
433 paths shown are relative to the repository root, not to the current
434 directory.
436 If `status.submoduleSummary` is set to a non zero number or true (identical
437 to -1 or an unlimited number), the submodule summary will be enabled for
438 the long format and a summary of commits for modified submodules will be
439 shown (see --summary-limit option of linkgit:git-submodule[1]). Please note
440 that the summary output from the status command will be suppressed for all
441 submodules when `diff.ignoreSubmodules` is set to 'all' or only for those
442 submodules where `submodule.<name>.ignore=all`. To also view the summary for
443 ignored submodules you can either use the --ignore-submodules=dirty command
444 line option or the 'git submodule summary' command, which shows a similar
445 output but does not honor these settings.
447 BACKGROUND REFRESH
448 ------------------
450 By default, `git status` will automatically refresh the index, updating
451 the cached stat information from the working tree and writing out the
452 result. Writing out the updated index is an optimization that isn't
453 strictly necessary (`status` computes the values for itself, but writing
454 them out is just to save subsequent programs from repeating our
455 computation). When `status` is run in the background, the lock held
456 during the write may conflict with other simultaneous processes, causing
457 them to fail. Scripts running `status` in the background should consider
458 using `git --no-optional-locks status` (see linkgit:git[1] for details).
460 SEE ALSO
461 --------
462 linkgit:gitignore[5]
466 Part of the linkgit:git[1] suite