NAME

git-status - Show the working tree status

SYNOPSIS

git status [<options>…​] [--] [<pathspec>…​]

DESCRIPTION

Displays paths that have differences between the index file and thecurrent HEAD commit, paths that have differences between the workingtree and the index file, and paths in the working tree that are nottracked by Git (and are not ignored by gitignore[5]). The firstare what you would commit by running git commit; the second andthird are what you could commit by running git add before runninggit commit.

OPTIONS

• -s
• —short

• Give the output in the short-format.

• -b

• —branch

• Show the branch and tracking info even in short-format.

• —show-stash

• Show the number of entries currently stashed away.

• —porcelain[=]

• Give the output in an easy-to-parse format for scripts.This is similar to the short output, but will remain stableacross Git versions and regardless of user configuration. Seebelow for details.

The version parameter is used to specify the format version.This is optional and defaults to the original version v1 format.

• —long

• Give the output in the long-format. This is the default.

• -v

• —verbose

• In addition to the names of files that have been changed, alsoshow the textual changes that are staged to be committed(i.e., like the output of git diff —cached). If -v is specifiedtwice, then also show the changes in the working tree thathave not yet been staged (i.e., like the output of git diff).

• -u[]

• —untracked-files[=]
• Show untracked files.

The mode parameter is used to specify the handling of untracked files.It is optional: it defaults to all, and if specified, it must bestuck to the option (e.g. -uno, but not -u no).

The possible options are:

• no - Show no untracked files.

• normal - Shows untracked files and directories.

• all - Also shows individual files in untracked directories.

When -u option is not used, untracked files and directories areshown (i.e. the same as specifying normal), to help you avoidforgetting to add newly created files. Because it takes extra workto find untracked files in the filesystem, this mode may take sometime in a large working tree.Consider enabling untracked cache and split index if supported (seegit update-index —untracked-cache and git update-index—split-index), Otherwise you can use no to have git statusreturn more quickly without showing untracked files.

The default can be changed using the status.showUntrackedFilesconfiguration variable documented in git-config[1].

• —ignore-submodules[=]

• Ignore changes to submodules when looking for changes. can beeither "none", "untracked", "dirty" or "all", which is the default.Using "none" will consider the submodule modified when it either containsuntracked or modified files or its HEAD differs from the commit recordedin the superproject and can be used to override any settings of theignore option in git-config[1] or gitmodules[5]. When"untracked" is used submodules are not considered dirty when they onlycontain untracked content (but they are still scanned for modifiedcontent). Using "dirty" ignores all changes to the work tree of submodules,only changes to the commits stored in the superproject are shown (this wasthe behavior before 1.7.0). Using "all" hides all changes to submodules(and suppresses the output of submodule summaries when the config optionstatus.submoduleSummary is set).

• —ignored[=]

• 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 caseindividual files in ignored directories aredisplayed.

• no - Show no ignored files.

• matching - Shows ignored files and directories matching anignore pattern.

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

• -z

• Terminate entries with NUL, instead of LF. This impliesthe —porcelain=v1 output format if no other format is given.

• —column[=]

• —no-column

• Display untracked files in columns. See configuration variablecolumn.status for option syntax.—column and —no-columnwithout options are equivalent to always and _never_respectively.

• —ahead-behind

• —no-ahead-behind

• Display or do not display detailed ahead/behind counts for thebranch relative to its upstream branch. Defaults to true.

• —renames

• —no-renames

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

• —find-renames[=]

• Turn on rename detection, optionally setting the similaritythreshold.See also git-diff[1] —find-renames.

• …​

• See the pathspec entry in gitglossary[7].

OUTPUT

The output from this command is designed to be used as a committemplate comment.The default, long format, is designed to be human readable,verbose and descriptive. Its contents and format are subject to changeat any time.

The paths mentioned in the output, unlike many other Git commands, aremade relative to the current directory if you are working in asubdirectory (this is on purpose, to help cutting and pasting). Seethe status.relativePaths config option below.

Short Format

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

XY PATH
XY ORIG_PATH -> PATH

where ORIG_PATH is where the renamed/copied contents camefrom. ORIG_PATH is only shown when the entry is renamed orcopied. The XY is a two-letter status code.

The fields (including the ->) are separated from each other by asingle space. If a filename contains whitespace or other nonprintablecharacters, that field will be quoted in the manner of a C stringliteral: surrounded by ASCII double quote (34) characters, and withinterior special characters backslash-escaped.

For paths with merge conflicts, X and Y show the modificationstates of each side of the merge. For paths that do not have mergeconflicts, X shows the status of the index, and Y shows the statusof the work tree. For untracked paths, XY are ??. Other statuscodes can be interpreted as follows:

• ' ' = unmodified

• M = modified

• A = added

• D = deleted

• R = renamed

• C = copied

• U = updated but unmerged

Ignored files are not listed, unless —ignored option is in effect,in which case XY are !!.

X          Y     Meaning

 [AMD]   not updated

M [ MD] updated in indexA [ MD] added to indexD deleted from indexR [ MD] renamed in indexC [ MD] copied in index[MARC] index and work tree matches[ MARC] M work tree changed since index[ MARC] D deleted in work tree[ D] R renamed in work tree

[ D] C copied in work tree

D D unmerged, both deletedA U unmerged, added by usU D unmerged, deleted by themU A unmerged, added by themD U unmerged, deleted by usA A unmerged, both added

U U unmerged, both modified

? ? untracked! ! ignored————————————————————————-

Submodules have more state and instead reportM the submodule has a different HEAD than recorded in the indexm the submodule has modified content? the submodule has untracked filessince modified content or untracked files in a submodule cannot be addedvia git add in the superproject to prepare a commit.

m and ? are applied recursively. For example if a nested submodulein a submodule contains an untracked file, this is reported as ? as well.

If -b is used the short-format status is preceded by a line

## branchname tracking info

Porcelain Format Version 1

Version 1 porcelain format is similar to the short format, but is guaranteednot to change in a backwards-incompatible way between Git versions orbased on user configuration. This makes it ideal for parsing by scripts.The description of the short format above also describes the porcelainformat, with a few exceptions:

• The user’s color.status configuration is not respected; color willalways be off.

• The user’s status.relativePaths configuration is not respected; pathsshown will always be relative to the repository root.

There is also an alternate -z format recommended for machine parsing. Inthat format, the status field is the same, but some other thingschange. First, the -> is omitted from rename entries and the fieldorder is reversed (e.g from -> to becomes to from). Second, a NUL(ASCII 0) follows each filename, replacing space as a field separatorand the terminating newline (but a space still separates the statusfield from the first filename). Third, filenames containing specialcharacters are not specially formatted; no quoting orbackslash-escaping is performed.

Any submodule changes are reported as modified M instead of m or single ?.

Porcelain Format Version 2

Version 2 format adds more detailed information about the state ofthe worktree and changed items. Version 2 also defines an extensibleset of easy to parse optional headers.

Header lines start with "#" and are added in response to specificcommand line arguments. Parsers should ignore headers theydon’t recognize.

Branch Headers

If —branch is given, a series of header lines are printed withinformation about the current branch.

Line                                     Notes

branch.oid <commit> | (initial) Current commit.

branch.head <branch> | (detached) Current branch.

branch.upstream <upstream_branch> If upstream is set.

branch.ab +<ahead> -<behind> If upstream is set and

                 the commit is present.

——————————————————————————————

Changed Tracked Entries

Following the headers, a series of lines are printed for trackedentries. One of three different line formats may be used to describean entry depending on the type of change. Tracked entries are printedin an undefined order; parsers should allow for a mixture of the 3line types in any order.

Ordinary changed entries have the following format:

1 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <path>

Renamed or copied entries have the following format:

2 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <X><score> <path><sep><origPath>

Field       Meaning

<XY> A 2 character field containing the staged and unstaged XY values described in the short format, with unchanged indicated by a "." rather than a space.<sub> A 4 character field describing the submodule state. "N…" when the entry is not a submodule. "S<c><m><u>" when the entry is a submodule. <c> is "C" if the commit changed; otherwise ".". <m> is "M" if it has tracked changes; otherwise ".". <u> is "U" if there are untracked changes; otherwise ".".<mH> The octal file mode in HEAD.<mI> The octal file mode in the index.<mW> The octal file mode in the worktree.<hH> The object name in HEAD.<hI> The object name in the index.<X><score> The rename or copy score (denoting the percentage of similarity between the source and target of the move or copy). For example "R100" or "C75".<path> The pathname. In a renamed/copied entry, this is the target path.<sep> When the -z option is used, the 2 pathnames are separated with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09) byte separates them.<origPath> The pathname in the commit at HEAD or in the index. This is only present in a renamed/copied entry, and tells where the renamed/copied contents came from.————————————————————————————

Unmerged entries have the following format; the first character isa "u" to distinguish from ordinary changed entries.

u <xy> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <path>

Field       Meaning

<XY> A 2 character field describing the conflict type as described in the short format.<sub> A 4 character field describing the submodule state as described above.<m1> The octal file mode in stage 1.<m2> The octal file mode in stage 2.<m3> The octal file mode in stage 3.<mW> The octal file mode in the worktree.<h1> The object name in stage 1.<h2> The object name in stage 2.<h3> The object name in stage 3.<path> The pathname.————————————————————————————

Other Items

Following the tracked entries (and if requested), a series oflines will be printed for untracked and then ignored itemsfound in the worktree.

Untracked items have the following format:

? <path>

Ignored items have the following format:

! <path>

Pathname Format Notes and -z

When the -z option is given, pathnames are printed as is andwithout any quoting and lines are terminated with a NUL (ASCII 0x00)byte.

Without the -z option, pathnames with "unusual" characters arequoted as explained for the configuration variable core.quotePath(see git-config[1]).

CONFIGURATION

The command honors color.status (or status.color — theymean the same thing and the latter is kept for backwardcompatibility) and color.status.<slot> configuration variablesto colorize its output.

If the config variable status.relativePaths is set to false, then allpaths shown are relative to the repository root, not to the currentdirectory.

If status.submoduleSummary is set to a non zero number or true (identicalto -1 or an unlimited number), the submodule summary will be enabled forthe long format and a summary of commits for modified submodules will beshown (see —summary-limit option of git-submodule[1]). Please notethat the summary output from the status command will be suppressed for allsubmodules when diff.ignoreSubmodules is set to all or only for thosesubmodules where submodule.<name>.ignore=all. To also view the summary forignored submodules you can either use the —ignore-submodules=dirty commandline option or the git submodule summary command, which shows a similaroutput but does not honor these settings.

BACKGROUND REFRESH

By default, git status will automatically refresh the index, updatingthe cached stat information from the working tree and writing out theresult. Writing out the updated index is an optimization that isn’tstrictly necessary (status computes the values for itself, but writingthem out is just to save subsequent programs from repeating ourcomputation). When status is run in the background, the lock heldduring the write may conflict with other simultaneous processes, causingthem to fail. Scripts running status in the background should considerusing git —no-optional-locks status (see git[1] for details).

SEE ALSO

gitignore[5]

GIT

Part of the git[1] suite