Home/ Questions/Q 6790373
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T17:43:04+00:00

I am working in a submodule and am having trouble untracking a folder full

  • 0

I am working in a submodule and am having trouble untracking a folder full of files 

$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
    #   modified:   public/javascripts/app/fckeditor/editor/skins/office2003/fck_dialog.css
    #   modified:   public/javascripts/app/fckeditor/editor/skins/office2003/fck_editor.css
    #   modified:   public/javascripts/app/fckeditor/editor/skins/silver/fck_dialog.css
    #   modified:   public/javascripts/app/fckeditor/editor/skins/silver/fck_editor.css
    #   modified:   public/javascripts/app/fckeditor/fckconfig.js
    #   modified:   public/javascripts/app/fckeditor/fckeditor.js
    #   modified:   public/javascripts/app/fckeditor/fckpackager.xml

I type

git reset --hard

which returns

HEAD is now at b2c5a77 nothing

However when I type 

git status

I am again greeted with the long list of files. I have tried to 

git clean -f

and also removed the entire submodule and checked out from the master server.
I have also tried to delete the entire project whom the submodule belongs to, pulled that and then initiated and updated the submodule but to no avail.

rm -rf project
git clone foo@bar.project.net:/home/rails/repo/gits/project.com
#Cloning into project...
#remote: Counting objects: 2452, done.
#remote: Compressing objects: 100% (2040/2040), done.
#remote: Total 2452 (delta 1238), reused 582 (delta 145)
#Receiving objects: 100% (2452/2452), 561.32 KiB | 438 KiB/s, done.
#Resolving deltas: 100% (1238/1238), done.
cd project.com
git submodule init
git submodule update
#Cloning into vendor/plugins/project_engine...
cd vendor/plugins/project_engine
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   public/javascripts/app/fckeditor/editor/skins/office2003/fck_dialog.css
#   modified:   public/javascripts/app/fckeditor/editor/skins/office2003/fck_editor.css
#   modified:   public/javascripts/app/fckeditor/editor/skins/silver/fck_dialog.css
#   modified:   public/javascripts/app/fckeditor/editor/skins/silver/fck_editor.css
#   modified:   public/javascripts/app/fckeditor/fckconfig.js
#   modified:   public/javascripts/app/fckeditor/fckeditor.js
#   modified:   public/javascripts/app/fckeditor/fckpackager.xml

The only thing that seems to remove the files is if I log on as another use on my Mac, which makes me think its a problem my local machine and not the repo itself.

I have also tried to uninstall and reinstall GIT and am currently running 1.7.5.4 install and complied with the help of brew (Ruby package manger).

How do I remove these files from git status?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I agree with Richard that this could stem from a case sensitivity/insensitivity problem. I will address that issue with this answer.

    Problem

    If a git commit contains two files whose names differ only in case, checking out that commit to a working directory in a case-insensitive filesystem causes problems. If the commit contains, for example, myfile and myFILE, git will create myfile, and then when it goes to create/update myFILE, the filesystem gives it a handle to myfile.

    This becomes apparent if myfile and myFILE have different contents in the repository. When checking out the files, the second one “wins” and the physical file contains the contents of the second file. When you do git status, the two files in the index both get compared to the same file in the working directory, and for the losing file, the contents don’t match.

    Verifying the Problem

    You could checkout the repository on a case-sensitive system to analyze and resolve everything there. Alternatively, git does provide enough tools to deal with this on your current system.

    The easy way to see if this is really the problem, is to make a trivial modification to one of files listed. Then, running git status should show both variants of the filename, since the working dir version does not match either version in the index:

    $ echo >> public/javascripts/app/fckeditor/fckpackager.xml
$ git status
Possible outcome:
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   ...
#   modified:   public/javascripts/app/fckeditor/fckpackager.xml
#   modified:   public/javascripts/app/fckeditor/FCKPACKAGER.xml

    Or, you can also use git ls-files to see what’s in the index:

    $ git ls-files public/javascripts/app/fckeditor/fckpackager.xml
public/javascripts/app/fckeditor/fckpackager.xml
public/javascripts/app/fckeditor/FCKPACKAGER.xml

    If you want to see exactly what is in each file, you can use git checkout-index to pull a file out of the index and save it somewhere (using a prefix so contents are written to separate files):

    $ git checkout-index --prefix=v1/ public/javascripts/app/fckeditor/fckpackager.xml
$ git checkout-index --prefix=v2/ public/javascripts/app/fckeditor/FCKPACKAGER.xml

    Resolution

    Once you have figured out which variant of each file you want to remove, you can remove it from the index using git rm --cached, which respects the case of the paths given to it:

    $ git rm --cached public/javascripts/app/fckeditor/FCKPACKAGER.xml

    then commit, and if necessary do another git reset --hard

    However, your comment about logging in as a different user and getting different result indicates there might be a different problem. That being the case I would see if there are any differences in the user-specific .gitconfig files.

    • 0