125
Short Format
126
~~~~~~~~~~~~
127
128
-In the short-format, the status of each path is shown as
128
+In the short-format, the status of each path is shown as one of these
129
+forms
130
130
- XY PATH1 -> PATH2
131
+ XY PATH
132
+ XY ORIG_PATH -> PATH
133
132
-where `PATH1` is the path in the `HEAD`, and the " `-> PATH2`" part is
133
-shown only when `PATH1` corresponds to a different path in the
134
-index/worktree (i.e. the file is renamed). The `XY` is a two-letter
135
-status code.
134
+where `ORIG_PATH` is where the renamed/copied contents came
135
+from. `ORIG_PATH` is only shown when the entry is renamed or
136
+copied. The `XY` is a two-letter status code.
137
138
The fields (including the `->`) are separated from each other by a
139
single space. If a filename contains whitespace or other nonprintable
169
[MARC] index and work tree matches
170
[ MARC] M work tree changed since index
171
[ MARC] D deleted in work tree
172
+ [ D] R renamed in work tree
173
+ [ D] C copied in work tree
174
-------------------------------------------------
175
D D unmerged, both deleted
176
A U unmerged, added by us
288
of similarity between the source and target of the
289
move or copy). For example "R100" or "C75".
290
<path> The pathname. In a renamed/copied entry, this
288
- is the path in the index and in the working tree.
291
+ is the target path.
292
<sep> When the `-z` option is used, the 2 pathnames are separated
293
with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
294
byte separates them.
292
- <origPath> The pathname in the commit at HEAD. This is only
293
- present in a renamed/copied entry, and tells
294
- where the renamed/copied contents came from.
295
+ <origPath> The pathname in the commit at HEAD or in the index.
296
+ This is only present in a renamed/copied entry, and
297
+ tells where the renamed/copied contents came from.
298
--------------------------------------------------------
299
300
Unmerged entries have the following format; the first character is