Git discard changes in working directory submodule

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 - Completely remove commits from an unrelated remote that was added accidentally
  • Unable to use bash script to remove files from git history
  • Stage hunk non-interactively in git
  • git: Can I stash an untracked file without adding it to the index?
  • How do I install Gitlab to run on a Subgit repository?
  • Push to remote on GitHub pointed to a new server IP instead
  • 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?

  • Pycharm and bitbucket plugin
  • Why am I getting a “destination path '.' already exists” error when trying clone from my webfaction server?
  • Push Git Project to Local Directory
  • Installing Git on Eclipse
  • How to solve'fatal: index-pack failed'?
  • How to pull a branch deletion in git?
  • 4 Solutions collect form web for “Git discard changes in working directory submodule”

    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.

    For cleaning untracked file, you should use

    git clean -xdf

    instead of

    git clean -f only

    -d
    Remove untracked directories in addition to untracked files. If an untracked
    directory is managed by a different git repository, it is not removed by
    default. Use -f option twice if you really want to remove such a directory.

    -x
    Don’t use the ignore rules. This allows removing all untracked files,
    including build products. This can be used (possibly in conjunction with git
    reset) to create a pristine working directory to test a clean build.

    You might be experiencing a case sensitivity problem. By default, Mac filesystems are case preserving but not case sensitive.

    Git itself is case sensitive. If you don’t have a case sensitive filesystem and there are two files checked in whose names differ only by case, git status will show one of the files as modified (assuming the contents of the two files is different). If you have two directories whose names differ only by case (e.g., fckeditor and FCKeditor), then Git may show lots of modified files.

    Try creating a case-sensitive volume and run git clone in there.

    Change to the submodule directory – it is its own repo – before you do operations on that submodule repo. You should then be able to clean and fix the sub-module repo ‘in the usual ways’.

    The various sub-module articles (progit & git community book), while they do mention it, aren’t as clear as needed to pick that point.

    Git Baby is a git and github fan, let's start git clone.