How can I remove an unstaged file without altering the repository?

167 views Asked by At

I recently cloned a GitHub Repository to my computer (Windows 11 Dell). The cloning process went fine, but when I checked the status it shows two of the files were deleted and are waiting to commit the changes to the repository.

$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        deleted:    gfx/interface/goals/TRM_Army.png
        deleted:    gfx/interface/goals/TRM_Navy.png

The issue is here is that I cannot update this cloned repository as long as those files are present, and nothing I have tried has been able to remove them.

I've tried:

  • Normal discard from GitKraken (my default program)
  • git reset
  • git checkout
  • git restore
  • Stashing the files
  • git clean
  • Deleting and re-cloning the repository
  • Uninstalling and Reinstalling Git
  • git reflog
  • Case-Sensitivity
  • git rm
  • git config

All of these methods have failed to produce results. The best I've been able to do is unstage the files, but this is not helpful as I still cannot delete them. I have checked git diff but there are no differences that it can detect, only git status is detecting them. The error is being detected on four different programs: Git Bash, Git GUI, GitHub Desktop and GitKraken (though Git GUI and Git Bash don't show the errors anymore if they were unstaged). I am not able to commit the changes as it would delete the files from the repository, and I do not own nor do I have permission to alter the repository. Is there a way to remove these phantom deletions without altering the repository?

Git GUI is showing this:

deleted file mode 100644
Binary files a/gfx/interface/goals/TRM_Navy.png and /dev/null differ

TL;DR: I have phantom 'changes' that were not made but I cannot remove and I am not able to alter the repository in anyway from its' current condition. No solution that I have found so far has worked.

3

There are 3 answers

0
Angelblue1302 On BEST ANSWER

Issue appears to be on the repository's end, as it looks like the repository has duplicated the problematic files, with two copies of each one, varying only by case. I've messaged the repository about the glitched files, so hopefully they'll fix it at some point.

0
LeGEC On

From our exchange in the comments: the weird behavior you see is linked to a case sensitivity issue.

Two files, which differ only in casing, are stored in git, and you are checking out this content on a case insensitive filesystem. So only one of these two files exist on disk, and git thinks the other one is deleted.


The longterm fix is to fix the issue in the repository itself: avoid having two paths which differ only in casing stored in git -- it probably is a bug to start with.

In order to ease working with a case insensitive filesystem (such as NTFS) on a git repository, you can turn on the core.ignoreCase option in git:

# to turn it on for that repo only:
git config core.ignoreCase true

# to turn it on for all your repos on this machine:
git config --global core.ignoreCase true

If this central repository is mainly used by Windows users, you could also spread the word that other users should turn this option on on their side.

0
Nilpo On

If you are removing files from a tracked directory, you are creating a change to the repository that needs to be committed.

Weren't these files at some point added to your repository and committed?

In any case, if you wish to stop tracking files at any point (which includes removing them locally without committing the change), you simply need to use the untrack feature in Git.

git rm --cached myfile.txt
git update-index --assume-unchanged myfile.txt
git status

The first command will delete the file. The second instructs Git to ignore the change to the local file catalog. Finally, a look at the status should indicate no uncommitted changes.

Be warned though: while this works, there are only a few real-world scenarios where you would actually want to do this. It's time to rethink your working practices.

I use this procedure to add or change config files when working on public projects where I don't want to push commits containing secrets.