Git status reports deleted files which still exist

Question

My Git status is showing all files deleted in my working tree which is incorrect, they are still there.

To resolve it, I should execute git reset --hard which reset all my modifications to other files.

Any idea how to solve it or how did it happen?

git status output:

On branch develop
Your branch is behind 'origin/develop' by 15 commits, and can be fast-forwarded.

Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

deleted:    .gitignore
deleted:    v3/.gitignore
deleted:    v3/index-test.php
deleted:    v3/index.php
deleted:    v3/protected/.gitignore
deleted:    v3/protected/.htaccess
deleted:    v3/protected/Gruntfile.js

Edit: The above is not the complete git status output. Those files that I was working on are not staged for deletion.

It's helpful to show the output here, even if it's trimmed a bit and paths are obscured. Also, it's helpful to talk about what you did leading up to this issue. It sounds to me like the files are staged for delete in the index, but present in the working copy. But I can't really tell from your description. — John Szakmeister, Oct 08 '13 at 10:05
yes, they are staged for delete. I'll add the `git status` output to the question. — bolbol, Oct 08 '13 at 10:08
Is that the entirety of your `git status` output, or did you snip it? The reason I ask is because you say you have modifications to other files, and from your `git status` output, it doesn't appear that way. — John Szakmeister, Oct 08 '13 at 10:31
That's not the entire status output, those files that I was working on are not staged — bolbol, Oct 09 '13 at 01:35

score 5 · Answer 1 · answered Oct 09 '13 at 10:52

If the only issue is that the some files have been removed from the index, but are still in the working tree, then all you need to do is:

git reset

By default, git reset defaults to mixed mode which does this:

--mixed

Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what has not been updated. This is the default action.

So it will leave your changes intact but unstage everything. If you find that the files are actually missing, then you'll need to check them out to restore them:

git checkout -- path/to/file/or/dir

You could parse the short form of git status using cut and xargs to help do this if you have lots of files. I'll leave that as an exercise for the reader though, since you're claiming that all the files are there.

```git reset```worked for me after cloud sync seemingly messed up the folder. Thanks! — intagli, Aug 11 '20 at 12:25

score 2 · Answer 2 · answered Oct 09 '13 at 10:59

2

if you deleted a file from local disk using

rm file.name

and if file.name was already checked into git. Then you should actually issue this command

git rm file.name

to tell git that you don't want it to track that file anymore

answered Oct 09 '13 at 10:59

Litmus

10,558
6
29
44

score 1 · Answer 3 · answered Oct 08 '13 at 08:05

1

  git co my_annoying_file
  git rm my_annoying_file
  git commit -m "removing annoying file"

now they are truly deleted from git tracking

...also git reset --hard may be to brittle for this scenario, consider git reset HEAD my_annoying_file

answered Oct 08 '13 at 08:05

equivalent8

13,754
8
81
109

thanks. but it's not just a single annoying file.. it's the whole working tree. – bolbol Oct 08 '13 at 09:21
same should apply to folder, but it sounds like you have git repository inside git repository. Try to check if you have folder called `.git` in that folder that causing an issue – equivalent8 Oct 09 '13 at 15:57
there is a .git directory which belongs to git-flow, will double check if that's the source of problem. thanks. – bolbol Oct 11 '13 at 10:39

Git status reports deleted files which still exist

3 Answers3

Linked