Re: git rm --cached

Jing Xue [off-list ref] 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'.

You probably want to use git reset HEAD -- 1.txt to unstage
modification on 1.txt

-- 
Rémi Vanicat