I thought, of course, it's because those 2 files are still untracked.
If this is the case, perhaps what you want is git add -u
or git add -u .
. This is very different from git add .
, since -u
means update. One must then ask the obvious question: update what? This is answered in the documentation:
-u
, --update
Update the index just where it
already has an entry matching <pathspec>. This removes as well
as modifies index entries to match the working tree, but adds no
new files.
If no <pathspec> is given when -u
option is used, all
tracked files in the entire working tree are updated (old
versions of Git used to limit the update to the current directory
and its subdirectories).
So that's the answer: -u
means update Git's index. The index is also known as the staging area, and it holds a copy of every file, ready to be committed, in exactly the form that Git will use when making the next commit. Updating the index therefore updates the proposed next commit.
Note that if some file exists in Git's index, but you have removed it from your working tree, git add -u
will remove the file from Git's index. That is, the proposed next commit now also lacks the file, just like the working tree. Once you've done this, a later git add -u
won't re-add the file, as it's already absent from Git's index. You'd need a non--u
git add
to put the file into Git's index, so that git add -u
will notice if the working tree copy has been modified since then, and pick up the new file content.
The parenthetical remark about old versions of Git is describing how git add -u
(with no files listed) worked in Git version 1.x. The new 2.x behavior examines places above the current working directory; to get the Git 1.x behavior, use git add -u .
. This works because .
means the current working directory and all subdirectories, which is of course how Git 1.x interpreted a bare git add -u
.