On Wed, 1 Jun 2016 08:30:55 -0700 (PDT)
Sharan Basappa <sharan.basa...@gmail.com> wrote:
> I need some help on git status.
> When I do git status in my project directory, I see 3 categories as
> 1) Changes to be committed:
> 2) Changed but not updated:
> 3) Untracked files:
> Under "Changes to be committed" - I see files marked as modified &
> new file
> I assume that new file here means that an added file isn't in the
> I assume that modified here means that a file that is in the
> repository has been modified and also added
> Under "Changed but not updated" - I see files marked as modified
> I assume that modified here means that file has changed but not added
> to the repository.
> Are my assumptions in blue font correct?
Please note that not all subscribers read this mailing list using the
Google Groups web interface. I, for one, read it using a conventional
mail reader. So I (luckily) see no colors on your text, and no other
formatting. Please take this fact into account next time and try to
formulate your question by using plain English words ;-)
> There are files that are listed both under "Changes to be
> committed" (as new file) & "Changed but not updated" (as modified
> file). For a moment if we ignore untracked files, how do I make sure
> that I have added appropriate files before committing?
> Also, what does git do if I add a file second time without modifying
Well, IMO this is best explained not by asking your questions directly
but rather explaining the reasons `git status` shows you your stuff the
way it does.
Fact 1: unless you use a short-cut command such as `git commit -a`
or `git commit path/to/file ...`, the new commit is created from the
contents of the staging area ("the index").
Fact 2: you add changes you want to go to the next commit into the index
by means of running `git add` on a file whose changes you want to add.
Now when you run `git add path/to/file`, there are two possible cases:
1. The file by that name is already in the index.
2. There is no file by that name recorded in the index.
In the first case the new contents taken from the specified file in
your work tree replaces that of the matching entry in the index.
In the second case the entry in the index is created.
Now recall that the contents of the index "is based" on the specific
commit -- that one referred to by the ref known as "HEAD".
Basically, when you do `git checkout foo` with the clean state of your
work tree Git 1) retargets HEAD to point at "foo"; 2) populates the
index with the data from the commit pointed at by HEAD (and hence the
tip of the branch "foo"); 3) makes sure the work tree has the same state
as the index.
So what `git staus` does is comparing the index to HEAD and the work
tree to the index. The differences between HEAD and the index are the
changes "to be committed"; the difference between the work tree and the
index and the changes which are "not staged". That's what those two
groups of changes mean.
The rest are merely details: the file about to be committed is marked
"new" if `git add` created a new entry for it in the index (the entry
was not there before and now it's there -- it's new!).
If you run `git rm --cached path/to/file` the entry for that file will
be deleted from the index, and `git status` will show it as "deleted".
When the contents of an entry was merely updated, it's displayed as
The term "updated" stems from the fact that `git add` operating on an
entry already existing in the index _updates_ it, so "changed but not
updated" means "changed locally but `git add` wasn't yet run to stage
the changes". Git could have `git add` and `git update` but since
creating a new entry in the index is just a byproduct of "updating" a
non-existing entry, the command is just `git add`.
As to running `git add` several times -- it won't do nothing (visible)
which is sensible: updating some contents with the same contents
means no change since Git tracks contents. Well, Git also tracks an
execution bit on file systems which support it (POSIX), so if you'd
change that bit on your file and `git add` it it would be listed as
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.