In the following scenario, why do I have to run 'git reset' following
'git rm --cached 1.txt' to revert to exactly where I was before 'git add
1.txt'?  Shouldn't 'git rm --cached' have done that already?

jingxue@fawkes:~/workspace/t1.git$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   1.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
jingxue@fawkes:~/workspace/t1.git$ git add 1.txt
jingxue@fawkes:~/workspace/t1.git$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   1.txt
#
jingxue@fawkes:~/workspace/t1.git$ git rm --cached 1.txt
rm '1.txt'
jingxue@fawkes:~/workspace/t1.git$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       deleted:    1.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       1.txt
jingxue@fawkes:~/workspace/t1.git$ git reset
1.txt: needs update
jingxue@fawkes:~/workspace/t1.git$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   1.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

Thanks.
-- 
Jing Xue

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html