tags:

views:

100

answers:

3

Git reports the following status on one of my branches:

# On branch awesome
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#       new file:   NEW.txt
#
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#
#       modified:   NEW.txt
#

This came about because I created NEW.txt then commanded:

git add NEW.txt

and later edited the file. Does this mean that doing git commit will commit the latest changes I've made to the file, or should I take extra caution?

+9  A: 

Git has the concept of a working directory and a staging area (the index). If you add a new file it gets added to the index. If you later edit that file it is only changed in your working copy. You need to add it to the index the same way you would a file that already existed.

So, in short, only things in the index get commited. commit -a will work here, or just add the file again when you've edited it like usual.

thenduks
+5  A: 

Git versions content rather than files. So, the content at the time you git add will be committed with the next commit.

Alan Haggai Alavi
The statement in bold clarified everything, thanks.
Frank Krueger
+4  A: 

In the case you've described, if you do a git commit you will commit the changes that were made before you did the git add (which may have been only creating an empty file), and not those after. You can use git diff to see the differences:

git diff

shows the differences between your working copy and the index, while

git diff --cached

shows the differences between the index and the HEAD. The differences shown by git diff --cached are what will be committed on git commit.

Greg Hewgill
To see the differences between the index and the HEAD `git diff --staged` works as well, and maybe is a bit more intuitive.
Ton van den Heuvel