it either contains
	untracked or modified files or its HEAD differs from the commit recorded
	in the superproject and can be used to override any settings of the
	'ignore' option in linkgit:git-config[1] or linkgit:gitmodules[5]. When
	"untracked" is used submodules are not considered dirty when they only
	contain untracked content (but they are still scanned for modified
	content). Using "dirty" ignores all changes to the work tree of submodules,
	only changes to the commits stored in the superproject are shown (this was
	the behavior before 1.7.0). Using "all" hides all changes to submodules
	(and suppresses the output of submodule summaries when the config option
	`status.submoduleSummary` is set).

--ignored[=<mode>]::
	Show ignored files as well.
+
--
The mode parameter is used to specify the handling of ignored files.
It is optional: it defaults to 'traditional'.

The possible options are:

	- 'traditional' - Shows ignored files and directories, unless
			  --untracked-files=all is specified, in which case
			  individual files in ignored directories are
			  displayed.
	- 'no'	        - Show no ignored files.
	- 'matching'    - Shows ignored files and directories matching an
			  ignore pattern.

When 'matching' mode is specified, paths that explicitly match an
ignored pattern are shown. If a directory matches an ignore pattern,
then it is shown, but not paths contained in the ignored directory. If
a directory does not match an ignore pattern, but all contents are
ignored, then the directory is not shown, but all contents are shown.
--

-z::
	Terminate entries with NUL, instead of LF.  This implies
	the `--porcelain=v1` output format if no other format is given.

--column[=<options>]::
--no-column::
	Display untracked files in columns. See configuration variable
	`column.status` for option syntax. `--column` and `--no-column`
	without options are equivalent to 'always' and 'never'
	respectively.

--ahead-behind::
--no-ahead-behind::
	Display or do not display detailed ahead/behind counts for the
	branch relative to its upstream branch.  Defaults to true.

--renames::
--no-renames::
	Turn on/off rename detection regardless of user configuration.
	See also linkgit:git-diff[1] `--no-renames`.

--find-renames[=<n>]::
	Turn on rename detection, optionally setting the similarity
	threshold.
	See also linkgit:git-diff[1] `--find-renames`.

<pathspec>...::
	See the 'pathspec' entry in linkgit:gitglossary[7].

OUTPUT
------
The output from this command is designed to be used as a commit
template comment.
The default, long format, is designed to be human readable,
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.

Short Format
~~~~~~~~~~~~

In the short-format, the status of each path is shown as one of these
forms

	XY PATH
	XY ORIG_PATH -> PATH

where `ORIG_PATH` is where the renamed/copied contents came
from. `ORIG_PATH` is only shown when the entry is renamed or
copied. The `XY` is a two-letter status code.

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
interior special characters backslash-escaped.

There are three different types of states that are shown using this format, and
each one uses the `XY` syntax differently:

* When a merge is occurring and the merge was successful, or outside of a merge
	situation, `X` shows the status of the index and `Y` shows the status of the
	working tree.
* When a merge conflict has occurred and has not yet been resolved, `X` and `Y`
	show the state introduced by each head of the merge, relative