What does the space in front of a few file names mean on doing git status -s?

Question

When I do git status -s I get the following output:

 M package.json
D  public/ewew.js
 M script.sh
M  src/TaskList.js
 D test.js
AD test2.js

What does the space in the beginning of few lines mean? (1st, 3rd and 5th line)

Answer 1

git status -s shows a two-letter status code in front of the file name, and you can find the explanation in the documentation:

X          Y     Meaning
-------------------------------------------------
          [MD]   not updated
M        [ MD]   updated in index
A        [ MD]   added to index
D         [ M]   deleted from index
R        [ MD]   renamed in index
C        [ MD]   copied in index
[MARC]           index and work tree matches
[ MARC]     M    work tree changed since index
[ MARC]     D    deleted in work tree
-------------------------------------------------
D           D    unmerged, both deleted
A           U    unmerged, added by us
U           D    unmerged, deleted by them
U           A    unmerged, added by them
D           U    unmerged, deleted by us
A           A    unmerged, both added
U           U    unmerged, both modified
-------------------------------------------------
?           ?    untracked
!           !    ignored
-------------------------------------------------

In your case, the X is space so this one applies:

X          Y     Meaning
-------------------------------------------------
          [MD]   not updated

Answer 2

Along with the other things it does, git status runs two (not one, but two) git diff commands. Therefore, when showing you a --short or -s status output, it needs to summarize the results of both diffs—which is why there are two positions for each possible status letter.

Remember that Git has, at all times, up to three copies of each file.¹ There's one instance of, e.g., package.json in the HEAD commit, a second version of package.json in the index (also called the staging area or the cache), and a third version of package.json in the work-tree.

The version of package.json in the current commit can never be changed, because no file in any commit can ever be changed. (You can change which commit is current, which will change the HEAD version of the file by changing HEAD itself: e.g., instead of HEAD being ac0ffee, maybe now HEAD is feeddad. But the files stored in those commits are always stored in those commits, forever.)

The version of package.json that is stored in the index, though, you can change at any time. You can't see it very well because it's stored in an internal, Git-only form, but you can get it out of the index and look at it, or put something different into the index, whenever you like.

The version of package.json that is stored in your work-tree, you can change at any time. You can see it and change it easily, because it's stored in the ordinary format that your computer uses for any file.

Diagrammatically:

  HEAD          index         work-tree
--------       --------       --------
package.json   package.json   package.json
public/ewew.js
script.sh      script.sh      script.sh
           :              :
               test2.js

The git status command first compares the HEAD version to the index version, then compares the index version to the work-tree version.

The status for this test2.js, for instance, is AD: this means it's missing in HEAD, so for HEAD-vs-index, it has been added, and then it is missing again in the work-tree, so for index-vs-work-tree, it has been deleted.

The status for script.sh is space-M, so the versions in HEAD and the index match (space) but the versions in the index and the work-tree differ (M). The status for src/TaskList.js is M-space, so the version in HEAD is different from the version in the index, and the version in the index is the same as the version in the work-tree.

If you were to make a commit right now, what would go into the new commit is whatever is in the index right now. To see everything that is in the index right now, use git ls-files --stage. Usually, though, the difference between HEAD and the index—i.e., the files "staged for commit" or the first column of a short status—is more interesting. Likewise, the difference between the index and the work-tree—i.e., files you could stage for commit—is interesting, so that's why there is a second column.

---

¹Technically, Git has, at any time, up to five copies of any one file, though sometimes as few as just one. This is because the index/staging-area is also used when doing a conflicted-file merge resolution—i.e., when you are in the middle of a conflicted merge. In this case, it holds three copies of one file: the merge-base version, the --ours version, and the --theirs version. But for this particular answer, just think of it as "three copies": don't worry about the other cases until you are doing a merge.