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'. You probably want to use git reset HEAD -- 1.txt to unstage modification on 1.txt -- Rémi Vanicat - 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
