# git rm --cached 10 messages from 2007-11-02 to 2007-11-14. Participants: Jing Xue, Remi Vanicat, Matthieu Moy, Jan Hudec, Junio C Hamano. Thread: https://gitlist.dev/t/10578 ## Jing Xue, 2007-11-02 02:17 Subject: git rm --cached Message-ID: <20071102021711.GA28703@fawkes.hq.digizenstudio.com> URL: https://gitlist.dev/e/20071102021711.GA28703%40fawkes.hq.digizenstudio.com ``` 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 ..." 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 ..." 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 ..." to unstage) # # deleted: 1.txt # # Untracked files: # (use "git add ..." 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 ..." 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, 2007-11-02 16:13 Subject: Re: git rm --cached Message-ID: <87mytwiq1f.dlv@vanicat.homelinux.org> URL: https://gitlist.dev/e/87mytwiq1f.dlv%40vanicat.homelinux.org In-Reply-To: <20071102021711.GA28703@fawkes.hq.digizenstudio.com> ``` Jing Xue 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, 2007-11-02 21:41 Subject: Re: git rm --cached Message-ID: <20071102174140.vobtdjxfwsgoc040@intranet.digizenstudio.com> URL: https://gitlist.dev/e/20071102174140.vobtdjxfwsgoc040%40intranet.digizenstudio.com In-Reply-To: <87mytwiq1f.dlv@vanicat.homelinux.org> ``` Quoting Remi Vanicat : > Jing Xue 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, 2007-11-03 09:39 Subject: Re: git rm --cached Message-ID: <87d4uris6y.dlv@vanicat.homelinux.org> URL: https://gitlist.dev/e/87d4uris6y.dlv%40vanicat.homelinux.org In-Reply-To: <20071102174140.vobtdjxfwsgoc040@intranet.digizenstudio.com> ``` Jing Xue 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, 2007-11-04 17:04 Subject: Re: git rm --cached Message-ID: URL: https://gitlist.dev/e/vpq1wb6x7ps.fsf%40bauges.imag.fr In-Reply-To: <20071102174140.vobtdjxfwsgoc040@intranet.digizenstudio.com> ``` Jing Xue 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 ``` ## Jan Hudec, 2007-11-11 14:05 Subject: Re: git rm --cached Message-ID: <20071111140518.GA3847@efreet.light.src> URL: https://gitlist.dev/e/20071111140518.GA3847%40efreet.light.src In-Reply-To: <20071102021711.GA28703@fawkes.hq.digizenstudio.com> ``` 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 ``` ## Jing Xue, 2007-11-12 00:38 Subject: [PATCH] replace reference to git-rm with git-reset in git-commit doc Message-ID: <20071112003845.GA7595@fawkes> URL: https://gitlist.dev/e/20071112003845.GA7595%40fawkes In-Reply-To: <20071111140518.GA3847@efreet.light.src> ``` 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 --- 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 -- `. 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, 2007-11-12 02:27 Subject: Re: [PATCH] replace reference to git-rm with git-reset in git-commit doc Message-ID: <7vsl3c8afm.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vsl3c8afm.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20071112003845.GA7595@fawkes> ``` Jing Xue 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 -- `. 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, 2007-11-12 04:43 Subject: [PATCH] RESUBMIT: replace reference to git-rm with git-reset in git-commit doc Message-ID: <20071112044300.GB7595@fawkes> URL: https://gitlist.dev/e/20071112044300.GB7595%40fawkes In-Reply-To: <7vsl3c8afm.fsf@gitster.siamese.dyndns.org> ``` 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 --- 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 -- `, +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, 2007-11-14 08:56 Subject: Re: [PATCH] RESUBMIT: replace reference to git-rm with git-reset in git-commit doc Message-ID: <7v8x51kxxj.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7v8x51kxxj.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20071112044300.GB7595@fawkes> ``` Jing Xue 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. ```