git rm --cached

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

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

Quoting Remi Vanicat [off-list ref]:

Jing Xue [off-list ref] writes:

quoted

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

Jing Xue [off-list ref] writes:

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.

Well, so it seem that to think of "git rm --cached" as inverse to 
"git add" is also confusing. The FAQ entry should probably be
rewrite. Or at least clarified.

 

-- 
Rémi Vanicat

On Thu, Nov 01, 2007 at 22:17:11 -0400, Jing Xue wrote:

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?

The message in git-commit suggesting to use 'git rm --cached' to unstage is
just plain wrong. It really should mention 'git reset'.

git rm, as the name suggests, *removes* the file. 

git reset, as the name suggests, reverts it to the state it was before (but,
somewhat confusingly, with path limit only resets the index, so no --cached
option there).

-- 
						 Jan 'Bulb' Hudec [off-list ref]

On Sun, Nov 11, 2007 at 03:05:18PM +0100, Jan Hudec wrote:

The message in git-commit suggesting to use 'git rm --cached' to unstage is
just plain wrong. It really should mention 'git reset'.

Hopefully this makes it clearer. I have also updated the faq in wiki to
clarify.

Signed-off-by: Jing Xue <redacted>
---
 Documentation/git-add.txt    |    1 +
 Documentation/git-commit.txt |   12 ++++++------
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 963e1ab..63829d9 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt

@@ -224,6 +224,7 @@ See Also
 --------
 gitlink:git-status[1]
 gitlink:git-rm[1]
+gitlink:git-reset[1]
 gitlink:git-mv[1]
 gitlink:git-commit[1]
 gitlink:git-update-index[1]

diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index e54fb12..7c63dd8 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt

@@ -154,12 +154,12 @@ EXAMPLES
 --------
 When recording your own work, the contents of modified files in
 your working tree are temporarily stored to a staging area
-called the "index" with gitlink:git-add[1].  Removal
-of a file is staged with gitlink:git-rm[1].  After building the
-state to be committed incrementally with these commands, `git
-commit` (without any pathname parameter) is used to record what
-has been staged so far.  This is the most basic form of the
-command.  An example:
+called the "index" with gitlink:git-add[1].  File changes
+previously staged can be removed with `git-reset
+HEAD -- <file>`.  After building the state to be committed
+incrementally with these commands, `git commit` (without any
+pathname parameter) is used to record what has been staged so
+far.  This is the most basic form of the command.  An example:
 
 ------------
 $ edit hello.c