10

I am wondering why when I do:

git add <file>

and after that, I do:

git rm --cached <file>

The file remains in deleted status in the stage área.

Here the example: enter image description here

I am only looking for an explanation about the 'deleted' status on the file.

Thanks

ferpega
  • 3,182
  • 7
  • 45
  • 65
  • You have to `git commit` the changes for them to take effect in the repository. That way, you can unstage the operation (if you change your mind, etc). It's basically listing the changes you've made to your working copy (in this case, the `rm` command) before they are committed to the repo. – Chris Mar 16 '13 at 22:57
  • Usually `green` colours means changes done to the index/stage. So, with your explanation, I must understand the `deleted` status is reflecting that a _delete_ is done on the index/stage. It is a bit strange but it has sense. – ferpega Mar 16 '13 at 23:32

2 Answers2

11

Try a git reset HEAD yourFile, instead of a git rm --cached.

A mixed reset will remove your file from the index, without removing it from the working tree.
See "Undo 'git add' before commit".

In your case, a git stash would need to precede the git reset, and then a git stash pop would restore your changes in progress, after the reset.

Regarding the 'deleted' status after a git rm --cached, that command registers in the index the deletion of the file, which is why you see it recorded as 'deleted' for the next commit.

The OP Ferpega insists:

I am asking why the deleted status is there as resulting of git rm --cached because this command should has the same behavior than git reset HEAD <file> as you can see in git rm.

Well, no, a git rm has not the same behavior as a [git reset][8].
Both will affect the index, but:

  • one (the git rm) will record a file for deletion on the next commit, hence the 'deleted' status,
  • the other (git reset) will copy HEAD to the index, resetting said index back to what the file was in HEAD.
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Git reset remove my changes on the working directory for the file. I don't want to loose my file-modifications. I _only_ want to unstage the file. So what I must to do is what I am doing. I only need an explanation for the `deleted`status. – ferpega Mar 16 '13 at 23:25
  • I have tested `git stash` before a 'git reset' and a `git stash pop` after that and it doesn't remove the file from the stage. At the end of the three command, all things remains as after the `git add` command. – ferpega Mar 16 '13 at 23:41
  • @Ferpega but the status, though, should be as *before* the `git add`, showing modifications *not* staged for the commit.. – VonC Mar 16 '13 at 23:43
2

You added the file to the index/cached (green in your screenshot) and told get you wanted to remove the file. Index/cache changes are only executed when a commit is done.

I'm thinking you probably put a file in the index/cache and then wanted to remove it (so it would not be committed).

The command to do this is in the message git status gives you (right above the circled deleted.

git reset HEAD <filename>
David Culp
  • 5,354
  • 3
  • 24
  • 32
  • Hi @David_Culp Yes, `git reset HEAD ` does what you say and I can use that command to get the same result. But I am not asking for doing something. I am asking why the `deleted` status is there as resulting of `git rm --cached` because this command should has the same behaviour than `git reset HEAD ` as you can see in: http://git-scm.com/docs/git-rm but it add another intermediate result you must `commit` to get the final result. – ferpega Mar 16 '13 at 23:57
  • 1
    @Ferpega `git rm --cached` has not the same behavior as a `git reset`, see my edited answer. – VonC Mar 17 '13 at 00:12