threads / discuss / 10578

git rm --cached

Subject: git rm --cached

## tl;dr

10 messages between Nov 2, 2007 and Nov 14, 2007.

replies: 9people: 6as markdown or json

Jing Xue· Nov 2, 2007, 02:17 UTC · lore

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
Remi Vanicat· Nov 2, 2007, 16:13 UTC · re: Jing Xue · lore

Re: git rm --cached

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'.

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

-- 
Rémi Vanicat
Jing Xue· Nov 2, 2007, 21:41 UTC · re: Remi Vanicat · lore

Re: git rm --cached

Quoting Remi Vanicat <vanicat@debian.org>:
Show 10 quoted lines
> 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
Remi Vanicat· Nov 3, 2007, 09:39 UTC · re: Jing Xue · lore

Re: git rm --cached

Jing Xue <jingxue@digizenstudio.com> 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
Matthieu Moy· Nov 4, 2007, 17:04 UTC · re: Jing Xue · lore

Re: git rm --cached

Jing Xue <jingxue@digizenstudio.com> writes:
Show 5 quoted lines
> 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.

The index is a full snapshot of "what will be commited". The interesting parts of the index are usually the ones which differ from either HEAD or the working tree, but the index do contain everything.

-- 
Matthieu
Jan Hudec· Nov 11, 2007, 14:05 UTC · re: Jing Xue · lore

Re: git rm --cached

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 <bulb@ucw.cz>
Jing Xue· Nov 12, 2007, 00:38 UTC · re: Jan Hudec · lore

[PATCH] replace reference to git-rm with git-reset in git-commit doc

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 <jingxue@digizenstudio.com>
---
 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
Junio C Hamano· Nov 12, 2007, 02:27 UTC · re: Jing Xue · lore

Re: [PATCH] replace reference to git-rm with git-reset in git-commit doc

Jing Xue <jingxue@digizenstudio.com> writes:
Show 19 quoted lines
> 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.
>
> 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].  File changes
> +previously staged can be removed with `git-reset
> +HEAD -- <file>`.

I think "changes ... can be removed" risks to give a confused mental model that somehow git tracks changes. "A file can be reverted back to that of the last commit with ..." would be less risky.

Jing Xue· Nov 12, 2007, 04:43 UTC · re: Junio C Hamano · lore

[PATCH] RESUBMIT: replace reference to git-rm with git-reset in git-commit doc

On Sun, Nov 11, 2007 at 06:27:57PM -0800, Junio C Hamano wrote:
> 
> I think "changes ... can be removed" risks to give a confused
> mental model that somehow git tracks changes.
I see what you mean. "Changes" shouldn't be the subject here.
> "A file can be
> reverted back to that of the last commit with ..."  would be
> less risky.

On top of that, I somehow still want to make it relevant to that git-reset instead of git-rm should be used to revert git-add. So how about this?

Signed-off-by: Jing Xue <jingxue@digizenstudio.com>
---
 Documentation/git-add.txt    |    1 +
 Documentation/git-commit.txt |   13 ++++++++-----
 2 files changed, 9 insertions(+), 5 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..4b26cae 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -154,11 +154,14 @@ 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
+called the "index" with gitlink:git-add[1].  A file can be
+reverted back, only in the index but not in the working tree,
+to that of the last commit with `git-reset HEAD -- <file>`,
+which effectively reverts `git-add` and prevents this file from
+participating in the next commit.  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:
 
 ------------
Junio C Hamano· Nov 14, 2007, 08:56 UTC · re: Jing Xue · lore

Re: [PATCH] RESUBMIT: replace reference to git-rm with git-reset in git-commit doc

Jing Xue <jingxue@digizenstudio.com> writes:
> On top of that, I somehow still want to make it relevant to that
> git-reset instead of git-rm should be used to revert git-add. So how
> about this?

Thanks. I'll fix up the log message and with a bit of rewording.

← back to recent threads