{"thread":{"id":"10578","subject":"git rm --cached","startedAt":"2007-11-02T02:17:11Z","lastAt":"2007-11-14T08:56:24Z","messageCount":10,"participants":["Jing Xue","Remi Vanicat","Matthieu Moy","Jan Hudec","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"57912","messageId":"20071102021711.GA28703@fawkes.hq.digizenstudio.com","threadId":"10578","inReplyTo":null,"subject":"git rm --cached","fromName":"Jing Xue","fromEmail":"jingxue@digizenstudio.com","sentAt":"2007-11-02T02:17:11Z","receivedAt":"2007-11-02T02:17:11Z","isPatch":false,"sender":{"key":"jingxue@digizenstudio.com","avatar":null},"body":"\nIn the following scenario, why do I have to run 'git reset' following\n'git rm --cached 1.txt' to revert to exactly where I was before 'git add\n1.txt'? Shouldn't 'git rm --cached' have done that already?\n\njingxue@fawkes:~/workspace/t1.git$ git status\n# On branch master\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n#\n# modified: 1.txt\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\njingxue@fawkes:~/workspace/t1.git$ git add 1.txt\njingxue@fawkes:~/workspace/t1.git$ git status\n# On branch master\n# Changes to be committed:\n# (use \"git reset HEAD ...\" to unstage)\n#\n# modified: 1.txt\n#\njingxue@fawkes:~/workspace/t1.git$ git rm --cached 1.txt\nrm '1.txt'\njingxue@fawkes:~/workspace/t1.git$ git status\n# On branch master\n# Changes to be committed:\n# (use \"git reset HEAD ...\" to unstage)\n#\n# deleted: 1.txt\n#\n# Untracked files:\n# (use \"git add ...\" to include in what will be committed)\n#\n# 1.txt\njingxue@fawkes:~/workspace/t1.git$ git reset\n1.txt: needs update\njingxue@fawkes:~/workspace/t1.git$ git status\n# On branch master\n# Changed but not updated:\n# (use \"git add ...\" to update what will be committed)\n#\n# modified: 1.txt\n#\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nThanks.\n-- \nJing Xue\n"},{"id":"58023","messageId":"87mytwiq1f.dlv@vanicat.homelinux.org","threadId":"10578","inReplyTo":"20071102021711.GA28703@fawkes.hq.digizenstudio.com","subject":"Re: git rm --cached","fromName":"Remi Vanicat","fromEmail":"vanicat@debian.org","sentAt":"2007-11-02T16:13:32Z","receivedAt":"2007-11-02T16:13:32Z","isPatch":false,"sender":{"key":"vanicat@debian.org","avatar":"https://gravatar.com/avatar/cd491a7f4c221349809a60f88fc21326b97cce2a705e318898aa74851db92409?d=mp&s=160"},"body":"Jing Xue writes:\n\n> In the following scenario, why do I have to run 'git reset' following\n> 'git rm --cached 1.txt' to revert to exactly where I was before 'git add\n> 1.txt'? Shouldn't 'git rm --cached' have done that already?\n\nObserved behavior are exactly what I expected: 'git rm --cached' mark\nthe file in the index as been deleted without deleting it in the\nworking directories, it did not but the index it was before the \n'git add 1.txt'.\n\nYou probably want to use git reset HEAD -- 1.txt to unstage\nmodification on 1.txt\n\n-- \nRémi Vanicat\n"},{"id":"58043","messageId":"20071102174140.vobtdjxfwsgoc040@intranet.digizenstudio.com","threadId":"10578","inReplyTo":"87mytwiq1f.dlv@vanicat.homelinux.org","subject":"Re: git rm --cached","fromName":"Jing Xue","fromEmail":"jingxue@digizenstudio.com","sentAt":"2007-11-02T21:41:40Z","receivedAt":"2007-11-02T21:41:40Z","isPatch":false,"sender":{"key":"jingxue@digizenstudio.com","avatar":null},"body":"\nQuoting Remi Vanicat :\n\n> Jing Xue writes:\n>\n>> In the following scenario, why do I have to run 'git reset' following\n>> 'git rm --cached 1.txt' to revert to exactly where I was before 'git add\n>> 1.txt'? Shouldn't 'git rm --cached' have done that already?\n>\n> Observed behavior are exactly what I expected: 'git rm --cached' mark\n> the file in the index as been deleted without deleting it in the\n> working directories, it did not but the index it was before the\n> 'git add 1.txt'.\n\nI was confused by two things I guess:\n\n1. I looked at the \"index\" as a staging area for _changes_ not files \nthemselves. So where 'man git-rm' says '--caches ... remove[s] the \npaths only from the index, leaving working tree files.' I took it to \nmean that it removes the changes on those paths, rather than staging a \nnew \"path deletion\" action for a later commit.\n\n2. The FAQ entry \"Why 'git rm' is not inverse of 'git add'\" says \"a \nnatural inverse of 'add' is 'un-add', and that operation is called 'rm \n--cached',...\" Now I realize that only applies to adding a new file, \nbut not changes on an existing file.\n\n> You probably want to use git reset HEAD -- 1.txt to unstage\n> modification on 1.txt\n\nSure.\n\nThanks.\n-- \nJing Xue\n"},{"id":"58086","messageId":"87d4uris6y.dlv@vanicat.homelinux.org","threadId":"10578","inReplyTo":"20071102174140.vobtdjxfwsgoc040@intranet.digizenstudio.com","subject":"Re: git rm --cached","fromName":"Remi Vanicat","fromEmail":"remi.vanicat@laposte.net","sentAt":"2007-11-03T09:39:17Z","receivedAt":"2007-11-03T09:39:17Z","isPatch":false,"sender":{"key":"remi.vanicat@laposte.net","avatar":null},"body":"Jing Xue writes:\n\n> 2. The FAQ entry \"Why 'git rm' is not inverse of 'git add'\" says \"a\n> natural inverse of 'add' is 'un-add', and that operation is called 'rm\n> --cached',...\" Now I realize that only applies to adding a new file,\n> but not changes on an existing file.\n\nWell, so it seem that to think of \"git rm --cached\" as inverse to \n\"git add\" is also confusing. The FAQ entry should probably be\nrewrite. Or at least clarified.\n\n \n\n-- \nRémi Vanicat\n"},{"id":"58283","messageId":"vpq1wb6x7ps.fsf@bauges.imag.fr","threadId":"10578","inReplyTo":"20071102174140.vobtdjxfwsgoc040@intranet.digizenstudio.com","subject":"Re: git rm --cached","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-11-04T17:04:47Z","receivedAt":"2007-11-04T17:04:47Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Jing Xue writes:\n\n> 1. I looked at the \"index\" as a staging area for _changes_ not files\n> themselves. So where 'man git-rm' says '--caches ... remove[s] the\n> paths only from the index, leaving working tree files.' I took it to\n> mean that it removes the changes on those paths, rather than staging a\n> new \"path deletion\" action for a later commit.\n\nThe index is a full snapshot of \"what will be commited\". The\ninteresting parts of the index are usually the ones which differ from\neither HEAD or the working tree, but the index do contain everything.\n\n-- \nMatthieu\n"},{"id":"59325","messageId":"20071111140518.GA3847@efreet.light.src","threadId":"10578","inReplyTo":"20071102021711.GA28703@fawkes.hq.digizenstudio.com","subject":"Re: git rm --cached","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-11T14:05:18Z","receivedAt":"2007-11-11T14:05:18Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Thu, Nov 01, 2007 at 22:17:11 -0400, Jing Xue wrote:\n> In the following scenario, why do I have to run 'git reset' following\n> 'git rm --cached 1.txt' to revert to exactly where I was before 'git add\n> 1.txt'? Shouldn't 'git rm --cached' have done that already?\n\nThe message in git-commit suggesting to use 'git rm --cached' to unstage is\njust plain wrong. It really should mention 'git reset'.\n\ngit rm, as the name suggests, *removes* the file. \n\ngit reset, as the name suggests, reverts it to the state it was before (but,\nsomewhat confusingly, with path limit only resets the index, so no --cached\noption there).\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"59406","messageId":"20071112003845.GA7595@fawkes","threadId":"10578","inReplyTo":"20071111140518.GA3847@efreet.light.src","subject":"[PATCH] replace reference to git-rm with git-reset in git-commit doc","fromName":"Jing Xue","fromEmail":"jingxue@digizenstudio.com","sentAt":"2007-11-12T00:38:45Z","receivedAt":"2007-11-12T00:38:45Z","isPatch":true,"sender":{"key":"jingxue@digizenstudio.com","avatar":null},"body":"On Sun, Nov 11, 2007 at 03:05:18PM +0100, Jan Hudec wrote:\n> \n> The message in git-commit suggesting to use 'git rm --cached' to unstage is\n> just plain wrong. It really should mention 'git reset'.\n\nHopefully this makes it clearer. I have also updated the faq in wiki to\nclarify.\n\nSigned-off-by: Jing Xue \n---\n Documentation/git-add.txt | 1 +\n Documentation/git-commit.txt | 12 ++++++------\n 2 files changed, 7 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex 963e1ab..63829d9 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -224,6 +224,7 @@ See Also\n --------\n gitlink:git-status[1]\n gitlink:git-rm[1]\n+gitlink:git-reset[1]\n gitlink:git-mv[1]\n gitlink:git-commit[1]\n gitlink:git-update-index[1]\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex e54fb12..7c63dd8 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -154,12 +154,12 @@ EXAMPLES\n --------\n When recording your own work, the contents of modified files in\n your working tree are temporarily stored to a staging area\n-called the \"index\" with gitlink:git-add[1]. Removal\n-of a file is staged with gitlink:git-rm[1]. After building the\n-state to be committed incrementally with these commands, `git\n-commit` (without any pathname parameter) is used to record what\n-has been staged so far. This is the most basic form of the\n-command. An example:\n+called the \"index\" with gitlink:git-add[1]. File changes\n+previously staged can be removed with `git-reset\n+HEAD -- `. After building the state to be committed\n+incrementally with these commands, `git commit` (without any\n+pathname parameter) is used to record what has been staged so\n+far. This is the most basic form of the command. An example:\n \n ------------\n $ edit hello.c\n"},{"id":"59416","messageId":"7vsl3c8afm.fsf@gitster.siamese.dyndns.org","threadId":"10578","inReplyTo":"20071112003845.GA7595@fawkes","subject":"Re: [PATCH] replace reference to git-rm with git-reset in git-commit doc","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-12T02:27:57Z","receivedAt":"2007-11-12T02:27:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jing Xue writes:\n\n> On Sun, Nov 11, 2007 at 03:05:18PM +0100, Jan Hudec wrote:\n>> \n>> The message in git-commit suggesting to use 'git rm --cached' to unstage is\n>> just plain wrong. It really should mention 'git reset'.\n>\n> Hopefully this makes it clearer. I have also updated the faq in wiki to\n> clarify.\n>\n> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\n> index e54fb12..7c63dd8 100644\n> --- a/Documentation/git-commit.txt\n> +++ b/Documentation/git-commit.txt\n> @@ -154,12 +154,12 @@ EXAMPLES\n> --------\n> When recording your own work, the contents of modified files in\n> your working tree are temporarily stored to a staging area\n> +called the \"index\" with gitlink:git-add[1]. File changes\n> +previously staged can be removed with `git-reset\n> +HEAD -- `.\n\nI think \"changes ... can be removed\" risks to give a confused\nmental model that somehow git tracks changes. \"A file can be\nreverted back to that of the last commit with ...\" would be\nless risky.\n"},{"id":"59423","messageId":"20071112044300.GB7595@fawkes","threadId":"10578","inReplyTo":"7vsl3c8afm.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] RESUBMIT: replace reference to git-rm with git-reset in git-commit doc","fromName":"Jing Xue","fromEmail":"jingxue@digizenstudio.com","sentAt":"2007-11-12T04:43:00Z","receivedAt":"2007-11-12T04:43:00Z","isPatch":true,"sender":{"key":"jingxue@digizenstudio.com","avatar":null},"body":"On Sun, Nov 11, 2007 at 06:27:57PM -0800, Junio C Hamano wrote:\n> \n> I think \"changes ... can be removed\" risks to give a confused\n> mental model that somehow git tracks changes.\n\nI see what you mean. \"Changes\" shouldn't be the subject here.\n\n> \"A file can be\n> reverted back to that of the last commit with ...\" would be\n> less risky.\n\nOn top of that, I somehow still want to make it relevant to that\ngit-reset instead of git-rm should be used to revert git-add. So how\nabout this?\n\nSigned-off-by: Jing Xue \n---\n Documentation/git-add.txt | 1 +\n Documentation/git-commit.txt | 13 ++++++++-----\n 2 files changed, 9 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex 963e1ab..63829d9 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -224,6 +224,7 @@ See Also\n --------\n gitlink:git-status[1]\n gitlink:git-rm[1]\n+gitlink:git-reset[1]\n gitlink:git-mv[1]\n gitlink:git-commit[1]\n gitlink:git-update-index[1]\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex e54fb12..4b26cae 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -154,11 +154,14 @@ EXAMPLES\n --------\n When recording your own work, the contents of modified files in\n your working tree are temporarily stored to a staging area\n-called the \"index\" with gitlink:git-add[1]. Removal\n-of a file is staged with gitlink:git-rm[1]. After building the\n-state to be committed incrementally with these commands, `git\n-commit` (without any pathname parameter) is used to record what\n-has been staged so far. This is the most basic form of the\n+called the \"index\" with gitlink:git-add[1]. A file can be\n+reverted back, only in the index but not in the working tree,\n+to that of the last commit with `git-reset HEAD -- `,\n+which effectively reverts `git-add` and prevents this file from\n+participating in the next commit. After building the state to\n+be committed incrementally with these commands, `git commit`\n+(without any pathname parameter) is used to record what has\n+been staged so far. This is the most basic form of the\n command. An example:\n \n ------------\n"},{"id":"59828","messageId":"7v8x51kxxj.fsf@gitster.siamese.dyndns.org","threadId":"10578","inReplyTo":"20071112044300.GB7595@fawkes","subject":"Re: [PATCH] RESUBMIT: replace reference to git-rm with git-reset in git-commit doc","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-14T08:56:24Z","receivedAt":"2007-11-14T08:56:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jing Xue writes:\n\n> On top of that, I somehow still want to make it relevant to that\n> git-reset instead of git-rm should be used to revert git-add. So how\n> about this?\n\nThanks. I'll fix up the log message and with a bit of\nrewording.\n"}]}