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 PATHXY 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.
There are three different types of states that are shown using this format, andeach one uses the XY syntax differently:
When a merge is occurring and the merge was successful, or outside of a mergesituation,
Xshows the status of the index andYshows the status of theworking tree.When a merge conflict has occurred and has not yet been resolved,
XandYshow the state introduced by each head of the merge, relative to the commonancestor. These paths are said to be unmerged.When a path is untracked,
XandYare always the same, since they areunknown to the index.??is used for untracked paths. Ignored files arenot listed unless--ignoredis used; if it is, ignored files are indicatedby!!.
Note that the term merge here also includes rebases using the default--merge strategy, cherry-picks, and anything else using the merge machinery.
In the following table, these three classes are shown in separate sections, andthese characters are used for X and Y fields for the first two sections thatshow tracked paths:
' ' = unmodified
M = modified
T = file type changed (regular file, symbolic link or submodule)
A = added
D = deleted
R = renamed
C = copied (if config option status.renames is set to "copies")
U = updated but unmerged
X Y Meaning------------------------------------------------- [AMD] not updatedM [ MTD] updated in indexT [ MTD] type changed in indexA [ MTD] added to indexD deleted from indexR [ MTD] renamed in indexC [ MTD] copied in index[MTARC] index and work tree matches[ MTARC] M work tree changed since index[ MTARC] T type changed in work tree since index[ MTARC] D deleted in work tree R renamed in work tree 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 addedU U unmerged, both modified-------------------------------------------------? ? untracked! ! ignored-------------------------------------------------
Submodules have more state and instead report
M = the submodule has a different HEAD than recorded in the index
m = the submodule has modified content
? = the submodule has untracked files
This is since 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.
See AlsoProfiles in Visual Studio CodeThe 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.------------------------------------------------------------
Stash Information
If --show-stash is given, one line is printed showing the number of stashentries if non-zero:
# stash <N>
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]).
