Quoting Remi Vanicat <vanicat@xxxxxxxxxx>:
Jing Xue <jingxue@xxxxxxxxxxxxxxxxx> writes:
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?
Observed behavior are exactly what I expected: 'git rm --cached' mark
the file in the index as been deleted without deleting it in the
working directories, it did not but the index it was before the
'git add 1.txt'.
I was confused by two things I guess:
1. I looked at the "index" as a staging area for _changes_ not files
themselves. So where 'man git-rm' says '--caches ... remove[s] the
paths only from the index, leaving working tree files.' I took it to
mean that it removes the changes on those paths, rather than staging a
new "path deletion" action for a later commit.
2. The FAQ entry "Why 'git rm' is not inverse of 'git add'" says "a
natural inverse of 'add' is 'un-add', and that operation is called 'rm
--cached',..." Now I realize that only applies to adding a new file,
but not changes on an existing file.
You probably want to use git reset HEAD -- 1.txt to unstage
modification on 1.txt
Sure.
Thanks.
--
Jing Xue
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
