Same files listed as both untracked and deleted

Question

Running git status in a Git repository, I get:

Changes not staged for commit:
  (use \"git add/rm ...\" to update what will be commi         


        

Answer 1

I had a very similar problem, discussed here Git doesn't stage my files any longer, and reports them as both "deleted" and "untracked". Why is that, and how to avoid it?

I found that :

• Using git add --all worked fine to stage

• Using git add -A did not work... even if it is supposed to be equivalent to the first

• Putting blank space may have been your problem, but it was not what caused mine :( it remains unresolved. FYI, I am working on Mac OS 10.10

• I still have the problem any time I add my file with the simple command git add filename (without space), and still resolve it by adding everything (git add --all) So it is a little bit of a hassle (for both being not handy, and remaining unexplained) but still I can go on with my work.

Here is the illustration of what worked, what did not, what recreated the problem, and what solved it back:

$ git add --all
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   Challenge28.py
    modified:   ch28_NN.py

$ git add Challenge28.py
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    .gitignore
    modified:   Challenge28.py
    deleted:    ch28_NN.py
    deleted:    requirements.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    .gitignore
    ch28_NN.py
    requirements.txt

$ git add --all
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   Challenge28.py
    modified:   ch28_NN.py

$ git add Challenge28.py
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    .gitignore
    deleted:    Challenge28.py
    deleted:    ch28_NN.py
    deleted:    requirements.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    .gitignore
    Challenge28.py
    ch28_NN.py
    requirements.txt

$ git add -A
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    .gitignore
    deleted:    Challenge28.py
    deleted:    ch28_NN.py
    deleted:    requirements.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    .gitignore
    Challenge28.py
    ch28_NN.py
    requirements.txt

$ git add --all
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   Challenge28.py
    modified:   ch28_NN.py

Answer 2

It was actually a very simple thing: the files had been committed with a space at the end of the filename. Apparently Windows cannot handle this, and automatically removes the space every time (after clone, after checkout, etc.).

So Git shows the correct information, the file "path/to/file1.sql " has been deleted, and the file "path/to/file1.sql" is new (sorry this didn't show in the question, now that I now I corrected it to show the space in the sample Git output).

I couldn't notice this at first, because I simply lsed the content of the directory /path/to/ on Linux after seeing that git status was fine there, and tried to debug everything in Windows (not possible, unless you somehow notice that space by selecting the right part of the Git output). While I was performing an additional check on the filenames (on Linux) thanks to Vampire's comment I obtained the strange result

ls /path/to/file1.sql
ls: file not found

After pressing TAB and seeing "/path/to/file1.sql\ " I figured it out. I think the problem is quite trivial, but since it doesn't happen everyday that someone commits files with a space at the end of the name, I think it can take a while to figure out there is no real problem with Git.

So I'm going to leave the question and the answer for now, if you disagree just downvote and I'll delete everything.

Thanks to everyone who helped in the comments.