git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git rm --cached

From
Remi Vanicat <vanicat@debian.org>
Date
Nov 2, 2007, 16:13 UTC
Message-ID
<87mytwiq1f.dlv@vanicat.homelinux.org>
In-Reply-To
<20071102021711.GA28703@fawkes.hq.digizenstudio.com>
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
Previous: Jing XueNext: Jing Xue
Message 2 of 10 in “git rm --cached”
  1. Jing XueNov 2, 2007
  2. Remi VanicatNov 2, 2007
  3. Jing XueNov 2, 2007
  4. Remi VanicatNov 3, 2007
  5. Matthieu MoyNov 4, 2007
  6. Jan HudecNov 11, 2007
  7. replace reference to git-rm with git-reset in git-commit docJing Xue, Nov 12, 2007
  8. Junio C HamanoNov 12, 2007
  9. RESUBMIT: replace reference to git-rm with git-reset in git-commit docJing Xue, Nov 12, 2007
  10. Junio C HamanoNov 14, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.