From: Jing Xue <jingxue@digizenstudio.com>
Date: Fri, 02 Nov 2007 21:41:40 GMT
Subject: Re: git rm --cached
Message-ID: <20071102174140.vobtdjxfwsgoc040@intranet.digizenstudio.com>
In-Reply-To: <87mytwiq1f.dlv@vanicat.homelinux.org>


Quoting Remi Vanicat <vanicat@debian.org>:

> Jing Xue <jingxue@digizenstudio.com> 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