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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
