0

After I checked out a branch and did a "git pull" on it, git thinks that I have deleted a file:

> git status
On branch feature-support
Your branch is up to date with 'origin/feature-support'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        deleted:    mvnw

However, that is not true, as the mvnw file is still in the directory. I have tried the following commands from this answer and other answers and I am not able to unstage this deleted file, which is preventing me from unstashing some files:

git restore --staged mvnw
git reset -- mvnw
git checkout -- mvnw
git reset HEAD mvnw
git reset HEAD .
git reset HEAD
git restore --staged -- mvnw
git reset mvnw
git checkout mvnw
git checkout .
git reset --hard
git clean -fd
git clean -f

How can I unstage that deleted file?

EDIT: Running the git restore --staged . command resolved the issue for the mvnw file, however, a new deleted file showed up in Changes to be committed and I can't get it to go away:

deleted: our-project/src/test/resources/etc/ABCD-EFGH.
pacoverflow
  • 3,726
  • 11
  • 41
  • 71
  • 1
    `git restore --staged mvnw` will have unstaged the deletion. `git restore mvnw` will restore the file – evolutionxbox Mar 15 '23 at 00:24
  • No matter what I do, it is still listed in `Changed to be committed: deleted: mvnw`. How can I remove 'mvnw` from `Changes to be committed`? – pacoverflow Mar 15 '23 at 01:31
  • It appears you tried multiple things that should have unstaged the file. I wonder if there is some funky permissions things occurring where the index was written by a different user and you cannot modify it. Like another program running as admin/root, etc. Or maybe another program just has the index locked. – TTT Mar 15 '23 at 02:28
  • What OS are you on ? – LeGEC Mar 15 '23 at 03:24
  • @LeGEC Windows 10, running Git 2.34.1.windows.1 – pacoverflow Mar 15 '23 at 04:03
  • could it be a case sensitivity issue ? check what files are versioned in git: `git ls-files HEAD | grep -i msnw` and what files you have on disk: `ls | grep -i msnw` – LeGEC Mar 15 '23 at 04:14
  • @LeGEC Nothing is returned when I do `git ls-files HEAD` – pacoverflow Mar 15 '23 at 04:20
  • @pacoverflow: my bad, I meant `git ls-tree HEAD | grep -i mvnw`, and obviously, you should grep for the name of your file (`mvnw`, not the mistyped name `msnw` I wrote before). Does `ls | grep -i mvnw` show a line where `mvnw` would be spelled with a different casing ? (`Mvnw` or `MVNW` or ...) – LeGEC Mar 15 '23 at 05:11
  • @LeGEC I tried `git restore --staged .` which got rid of the `deleted: mvnw`, but oddly replaced it with a different file `deleted: our-project/src/test/resources/etc/ABCD-EFGH.` which is still on the disk. The `git ls-tree HEAD` command outputs info about the files/dirs in the current directory. Should I do something different for the `ABCD-EFGH` file? – pacoverflow Mar 15 '23 at 05:17
  • I think this will work: `git checkout HEAD -- mvnw`.. given everything you have tried, I wouldn't bet. Just in case, this should also work: `git show HEAD:mvnw > mvnw` even if indirectly. – eftshift0 Mar 15 '23 at 07:08

1 Answers1

0

For the mvnw file, I resolved the issue with the git restore --staged . command.

For the our-project/src/test/resources/etc/ABCD-EFGH. file, I resolved the issue with the git config core.protectNTFS false command. Viewing the our-project/src/test/resources/etc/ directory on GitHub, I can see 3 files:

ABCD-EFGH
ABCD-EFGH.
ABCD-EFGH.pdf

It appears Windows cannot handle a file named ABCD-EFGH. (with a dot at the end), and the git config core.protectNTFS false command resolves that. I still see deleted: our-project/src/test/resources/etc/ABCD-EFGH. in the Changes not staged for commit section, but it is not preventing any git operations like it did when it was listed under the Changes to be committed section.

pacoverflow
  • 3,726
  • 11
  • 41
  • 71