git rm --cached

git rm --cached

[Jing Xue]

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

Re: git rm --cached

[Remi Vanicat]

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

Re: git rm --cached

[Jing Xue]

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

Re: git rm --cached

[Remi Vanicat]

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

Re: git rm --cached

[Matthieu Moy]

Jing Xue <jingxue@digizenstudio.com> writes:

> 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

Re: git rm --cached

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

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>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Jing Xue]

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

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

[Junio C Hamano]

Jing Xue <jingxue@digizenstudio.com> writes:

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

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

[Jing Xue]

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:
 
 ------------

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

[Junio C Hamano]

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.