Files showing as modified directly after git clone












201














I'm having an issue with a repository at the moment, and though my git-fu is usually good, I can't seem to solve this issue.



When I clone this repository, then cd into the repo, git-status shows several files as changed. Note: I haven't opened the repo in any editor or anything.



I tried following this guide: http://help.github.com/dealing-with-lineendings/ but this didn't help at all with my issue.



I have tried git checkout -- . many times but it seems not to do anything.



Any help/ideas would be greatly appreciated



Update 1: I'm on a mac, and there are no submodules in the repo itself.



Update 2: the filesystem is "Journaled HFS+" filesystem on the mac, and is not case-sensitive. The files are one-line and about 79K each (yes, you heard right) so looking at git diff isn't particularly helpful. I have heard about doing git config --global core.trustctime false which might help, which i will try when i get back to the computer with the repo on it.



Update 3: changed details of filesystem with facts! and, I tried the git config --global core.trustctime false trick which didn't work very well.










share|improve this question




















  • 3




    What does git-diff tell you?
    – Josh Lee
    Feb 15 '11 at 22:56
















201














I'm having an issue with a repository at the moment, and though my git-fu is usually good, I can't seem to solve this issue.



When I clone this repository, then cd into the repo, git-status shows several files as changed. Note: I haven't opened the repo in any editor or anything.



I tried following this guide: http://help.github.com/dealing-with-lineendings/ but this didn't help at all with my issue.



I have tried git checkout -- . many times but it seems not to do anything.



Any help/ideas would be greatly appreciated



Update 1: I'm on a mac, and there are no submodules in the repo itself.



Update 2: the filesystem is "Journaled HFS+" filesystem on the mac, and is not case-sensitive. The files are one-line and about 79K each (yes, you heard right) so looking at git diff isn't particularly helpful. I have heard about doing git config --global core.trustctime false which might help, which i will try when i get back to the computer with the repo on it.



Update 3: changed details of filesystem with facts! and, I tried the git config --global core.trustctime false trick which didn't work very well.










share|improve this question




















  • 3




    What does git-diff tell you?
    – Josh Lee
    Feb 15 '11 at 22:56














201












201








201


63





I'm having an issue with a repository at the moment, and though my git-fu is usually good, I can't seem to solve this issue.



When I clone this repository, then cd into the repo, git-status shows several files as changed. Note: I haven't opened the repo in any editor or anything.



I tried following this guide: http://help.github.com/dealing-with-lineendings/ but this didn't help at all with my issue.



I have tried git checkout -- . many times but it seems not to do anything.



Any help/ideas would be greatly appreciated



Update 1: I'm on a mac, and there are no submodules in the repo itself.



Update 2: the filesystem is "Journaled HFS+" filesystem on the mac, and is not case-sensitive. The files are one-line and about 79K each (yes, you heard right) so looking at git diff isn't particularly helpful. I have heard about doing git config --global core.trustctime false which might help, which i will try when i get back to the computer with the repo on it.



Update 3: changed details of filesystem with facts! and, I tried the git config --global core.trustctime false trick which didn't work very well.










share|improve this question















I'm having an issue with a repository at the moment, and though my git-fu is usually good, I can't seem to solve this issue.



When I clone this repository, then cd into the repo, git-status shows several files as changed. Note: I haven't opened the repo in any editor or anything.



I tried following this guide: http://help.github.com/dealing-with-lineendings/ but this didn't help at all with my issue.



I have tried git checkout -- . many times but it seems not to do anything.



Any help/ideas would be greatly appreciated



Update 1: I'm on a mac, and there are no submodules in the repo itself.



Update 2: the filesystem is "Journaled HFS+" filesystem on the mac, and is not case-sensitive. The files are one-line and about 79K each (yes, you heard right) so looking at git diff isn't particularly helpful. I have heard about doing git config --global core.trustctime false which might help, which i will try when i get back to the computer with the repo on it.



Update 3: changed details of filesystem with facts! and, I tried the git config --global core.trustctime false trick which didn't work very well.







git git-clone






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 16 '11 at 21:24

























asked Feb 15 '11 at 20:24









Sam Elliott

2,05621216




2,05621216








  • 3




    What does git-diff tell you?
    – Josh Lee
    Feb 15 '11 at 22:56














  • 3




    What does git-diff tell you?
    – Josh Lee
    Feb 15 '11 at 22:56








3




3




What does git-diff tell you?
– Josh Lee
Feb 15 '11 at 22:56




What does git-diff tell you?
– Josh Lee
Feb 15 '11 at 22:56












16 Answers
16






active

oldest

votes


















131














I had the same problem on the Mac after cloning a repo, it would assume all files have been changed.



After running git config --global core.autocrlf input it was still marking all files as changed. After looking for a fix I came across .gitattributes file in the home directory which had the following.



* text=auto


I commented it out and any other cloned repositories from now on are working fine. Hope this helps anyone out there.






share|improve this answer



















  • 5




    Thanks! I finally found this after spending all evening toggling core.autocrlf and apply.whitespace. This worked. Thank-you.
    – xer0x
    Jul 5 '12 at 8:27






  • 5




    The offending line in .gitattributes came from Mathias Bynen's dotfiles, in case anyone else comes across this.
    – SeanPONeil
    Mar 19 '13 at 14:21






  • 28




    can anyone shed more light on this particular configuration? What does * text=auto do? What does it mean to remove it from .gitattributes? I see it fixes this problem for me, but I am not sure why it does so, and what it is really doing, and what possible issues it is possibly creating?
    – Dennis
    Feb 27 '14 at 18:24






  • 6




    @Dennis This setting helps normalize line endings, so deleting it is likely not the right answer. See this question's answer and this article. @Arrowmaster 's answer below was more helpful for me. I used git add and git commit which normalized the file and got rid of the issue.
    – jtpereyda
    Jun 29 '15 at 23:04








  • 2




    git config --global core.autocrlf input fixed it for me. Thanks.
    – dimiguel
    Oct 14 '15 at 15:01



















84














I got it. All the other developers are on ubuntu (i think), and thus have case-sensitive file systems. I, however, do not (as I'm on a mac). Indeed all the files had lowercase twins when I took a look at them using git ls-tree HEAD <path>.



I'll get one of them to sort it out.






share|improve this answer





















  • Did they ever sort it out? I'm possibly having the same issue.
    – Josh Johnson
    Feb 29 '12 at 12:13






  • 8




    Yeah, just get someone with a case-sensitive file system to delete all but one from each set of the files which would have duplicate filenames on a case-insensitive filesystem.
    – Sam Elliott
    Feb 29 '12 at 22:52






  • 1




    Just ran into the same issue since moving from Ubuntu to Mac. Thanks, your answer hit the nail on the head. Hope the upvote pushes it to the first position. :-)
    – chmac
    Apr 23 '13 at 11:31






  • 1




    @Dirk this is why there are multiple answers. I accepted the one that applied in my case, which is not unreasonable.
    – Sam Elliott
    Mar 11 '16 at 17:58






  • 1




    This was my issue as well - case insensitive MacOS. However git ls-tree HEAD <path> showed only a single file. I was able to see the duplicate files in the GitHub.com UI, however, and also use that UI to delete one version.
    – orion elenzil
    Apr 17 at 19:57



















56














git config core.fileMode false


solved this problem in my case



https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-config.html



TL;DR;



core.fileMode



If false, the executable bit differences between the index and the working tree are ignored; useful on broken filesystems like FAT. See git-update-index(1).



The default is true, except git-clone(1) or git-init(1) will probe and set core.fileMode false if appropriate when the repository is created.






share|improve this answer



















  • 2




    This also solved my problem :)
    – Anand Singh
    Dec 17 '15 at 12:20










  • solved also mine. thanks
    – Malith
    May 11 '16 at 6:41






  • 1




    But what does this do??
    – Siwel
    Sep 20 '16 at 22:12










  • I would also like to know what this does, because it worked for me as well.
    – Donato
    Oct 17 '16 at 22:28






  • 1




    When i did git diff, I found that the changes were in only file mode. git picks up on chmod -R 777 . which was caused when I ran my project and this config allowed me to ignore chmod changes by git stackoverflow.com/q/1580596/6207775
    – Ayushya
    Jul 9 '17 at 6:02



















51














I assume you are using Windows. That github page you linked has the details backwards. The problem is that CRLF line endings have been committed to the repo already and because you have core.autocrlf set to either true or input, git wants to convert the line-endings to LF so git status shows that every file is changed.



If this is a repo that you only want to access but have no involvement with you can run the following command to merely hide the issue without actually solving it.



git config core.autocrlf false





If this is a repo that you will be actively involved in and can commit changes to. You may wish to fix the problem by making a commit that changes all the line endings in the repo to use LF instead of CRLF and then take steps to prevent it from happening again in the future.

The following is taken directly from the gitattributes man page and should be preformed from a clean working directory.



echo "* text=auto" >>.gitattributes
rm .git/index # Remove the index to force git to
git reset # re-scan the working directory
git status # Show files that will be normalized
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"


If any files that should not be normalized show up in git status, unset their text attribute before running git add -u.



manual.pdf      -text


Conversely, text files that git does not detect can have normalization enabled manually.



weirdchars.txt  text





share|improve this answer

















  • 6




    I am not using windows.
    – Sam Elliott
    Feb 15 '11 at 22:05






  • 1




    By default on non-Windows systems, core.autocrlf is set to false. So you shouldn't have even experienced this problem if it is caused by line-endings. Could you give more details on your specific setup such as what git diff shows for those files that git status says are modified, also what filesystem are you using?
    – Arrowmaster
    Feb 15 '11 at 22:45












  • updated the question with answers to these questions. Will take another look over all the details in a second or two. I'm not sure what other members of the dev team are using
    – Sam Elliott
    Feb 16 '11 at 9:49






  • 1




    Thanks you Arrowmaster Answer. It helped me a lot!!! Thank you!!
    – sree
    Oct 25 '13 at 11:07












  • Great!! That second part works for me! Thank you!
    – Carlos Faria
    Dec 20 '13 at 9:30



















32














Please run the following commands. That might solve the issue.



# Remove everything from the index.
git rm --cached -r .

# Write both the index and working directory from git's database.
git reset --hard





share|improve this answer























  • None of the other solutions worked for me, but this one got me back up and running.
    – rainabba
    Oct 19 '16 at 23:45






  • 1




    I tried this one and it worked for me. Thank Mr. LIama!
    – Danniel Little
    Mar 8 '17 at 18:33










  • This makes my repository worse. On a branch that had no changes, I had 277 after running it. I had those same changes on other branches I switched to as well. Run with caution. I just recloned by repo and have 615 files modified. :(
    – Programmer Paul
    Jun 13 '17 at 16:01












  • this worked for me using git v2.7.4 with ubuntu (WSL) , Git for Windows v2.18.0.windows.1 and posh-git I have always had autocrlf false and the issue started in Git for Windows and posh-git after upgrading to 2.18.0 today
    – Jim Frenette
    Jun 24 at 1:33












  • I am amazed this works. Thanks for the help. For others going down this path, the files that were seemingly modified were all .png and .bmp files managed by git LFS
    – David Casper
    Nov 23 at 17:01



















15














In Visual Studio, if you are using Git, you can auto generate the .gitignore and .gitattributes files. The auto generated .getattributes file has the following line:



* text=auto


This line is near the top of the file. We just needed to comment the line out by adding a # to the front of it. After doing that, things operated as expected.






share|improve this answer



















  • 1




    Thanks, been struggling with this for aaaages
    – Andrew Berry
    Nov 11 '15 at 16:37










  • This was exactly my issue. Another developer had used GIT through VS instead of CLI and created this .gitattributes file.
    – Josh Maag
    Aug 23 '16 at 18:42



















11














The problem might also arise from differing file permissions, as was my case:



Fresh cloned repository (Windows, Cygwin):



$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑


Bare remote repository (Linux):



$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑





share|improve this answer































    3














    I had the same problem. Also with a Mac. Looking at the repo on a linux machine I noticed that I had two files:



    geoip.dat and GeoIP.dat



    Removed the deprecated one on the linux machine and cloned the repository again to the mac. I was not able to pull, commit, stash or pull from my copy of the repository when there were duplicates.






    share|improve this answer





























      3














      I wanted to add an answer more directed on "Why" this happens, because there is already a good answer on how to fix it.



      So, .gitattributes has a * text=auto setting, which causes this issue.



      In my case Files on GitHub’s master branch had rn endings. I have dialed up the settings on the repo to check-in with n endings. I don't know what git checks out though. It is supposed to check out with native endings onto my Linux box (n), but I guess it checked out the file with rn endings. Git complains because it sees the checked out rn endings that were in the repo and warns me that it will check in n settings. Hence files are "to be modified".



      That's my understanding for now.






      share|improve this answer





























        1














        I also just had the same problem. In my case I cloned the repo and some files were immediately missing.



        This was caused by the path to the file and the filename being too long for Windows. To resolve it clone the repo as close to the hdd root as possible to reduce the length of the path to the file e.g. clone it to C:AGitRepo instead of C:Users DocumentsyyyDesktopGitRepo






        share|improve this answer





























          1














          Edit file called: sudo gedit .git/config sudo vim .git/config



          [core]
          repositoryformatversion = 0
          filemode = false
          bare = false
          logallrefupdates = true
          [remote "origin"]
          url = kharadepramod@bitbucket.org:DigitalPlumbing/unicorn-magento.git
          fetch = +refs/heads/*:refs/remotes/origin/*
          [branch "master"]
          remote = origin
          merge = refs/heads/master
          [branch "productapproval"]
          remote = origin
          merge = refs/heads/productapproval


          Change filemode=true into filemode = false






          share|improve this answer





























            0














            I copied my local repository to another folder and a bunch of modified files showed up.
            My workaround was: I stashed the modified files and deleted the stash. The repository became clean.






            share|improve this answer





























              0














              I found that git was treating my files (.psd in this case) as text. Setting it to a binary type in the .gitattributes solved it.



              *.psd binary





              share|improve this answer





























                0














                I was having a similar problem and found this question.



                I was trying to do an interactive rebase, but it claimed there were some modified files, so it wouldn't let me do it right now. I tried EVERYTHING to get back to a clean repo, but nothing worked. None of the other answers helped. But this finally worked...



                git rm -rf the-folder-with-modified-stuff
                git ci -m 'WAT'


                Boom! Clean repo. Problem solved. Then I just had to drop the last commit when I did my rebase -i and finally everything was clean again.
                Bizarre!



                But I'm adding this solution here so that maybe if I ever run into this again I'll see this and try it. Thanks :D






                share|improve this answer





























                  0














                  For new versions of macOS this can be caused by a security feature of the OS.



                  In the repository I was working on, there was a binary file which had *.app as file type.
                  It was just some serialised data, but macOS treats all *.app files as an application and as this file was not downloaded by the user, the system deemed it insecure and added the com.apple.quarantine file attribute which makes sure the file can not be executed.



                  But setting this attribute on the file was also changing the file and it therefore showed up in the git change set without any way of reverting it.



                  You can check if you have the same problem by running $ xattr file.app



                  The solution is pretty simple, as long as you don't have to work with the file.
                  Just add *.app binary to your .gitattributes






                  share|improve this answer





























                    0














                    Same issue for me. I could see several images with the same name like "textField.png" and "textfield.png" in the remote Git repo but not on my local repo, I was only able to see "textField.png" wich was not used in the project's code.
                    It turns out most of my colleagues are on Ubuntu using ext4 filesystem whereas I'm on a Mac using APFS.



                    Thanks to Sam Elliott's answer, the solution was quite simple. First I asked a colleague on Ubuntu to delete the redundant file versions with the uppercase, then commit and push on remote.



                    Then I ran the following :



                    # Remove everything from the index.
                    git rm --cached -r .

                    # Write both the index and working directory from git's database.
                    git reset --hard


                    Finally, we decided that every developer should change his Git config to prevent this to ever happen again



                    # Local Git config
                    git config core.ignorecase = true


                    or



                    # Global Git config
                    git config --global core.ignorecase = true





                    share|improve this answer





















                    • It would be better if you just upvoted @kds's answer!
                      – Elharony
                      Dec 7 at 9:59











                    Your Answer






                    StackExchange.ifUsing("editor", function () {
                    StackExchange.using("externalEditor", function () {
                    StackExchange.using("snippets", function () {
                    StackExchange.snippets.init();
                    });
                    });
                    }, "code-snippets");

                    StackExchange.ready(function() {
                    var channelOptions = {
                    tags: "".split(" "),
                    id: "1"
                    };
                    initTagRenderer("".split(" "), "".split(" "), channelOptions);

                    StackExchange.using("externalEditor", function() {
                    // Have to fire editor after snippets, if snippets enabled
                    if (StackExchange.settings.snippets.snippetsEnabled) {
                    StackExchange.using("snippets", function() {
                    createEditor();
                    });
                    }
                    else {
                    createEditor();
                    }
                    });

                    function createEditor() {
                    StackExchange.prepareEditor({
                    heartbeatType: 'answer',
                    autoActivateHeartbeat: false,
                    convertImagesToLinks: true,
                    noModals: true,
                    showLowRepImageUploadWarning: true,
                    reputationToPostImages: 10,
                    bindNavPrevention: true,
                    postfix: "",
                    imageUploader: {
                    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
                    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
                    allowUrls: true
                    },
                    onDemand: true,
                    discardSelector: ".discard-answer"
                    ,immediatelyShowMarkdownHelp:true
                    });


                    }
                    });














                    draft saved

                    draft discarded


















                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f5009096%2ffiles-showing-as-modified-directly-after-git-clone%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown

























                    16 Answers
                    16






                    active

                    oldest

                    votes








                    16 Answers
                    16






                    active

                    oldest

                    votes









                    active

                    oldest

                    votes






                    active

                    oldest

                    votes









                    131














                    I had the same problem on the Mac after cloning a repo, it would assume all files have been changed.



                    After running git config --global core.autocrlf input it was still marking all files as changed. After looking for a fix I came across .gitattributes file in the home directory which had the following.



                    * text=auto


                    I commented it out and any other cloned repositories from now on are working fine. Hope this helps anyone out there.






                    share|improve this answer



















                    • 5




                      Thanks! I finally found this after spending all evening toggling core.autocrlf and apply.whitespace. This worked. Thank-you.
                      – xer0x
                      Jul 5 '12 at 8:27






                    • 5




                      The offending line in .gitattributes came from Mathias Bynen's dotfiles, in case anyone else comes across this.
                      – SeanPONeil
                      Mar 19 '13 at 14:21






                    • 28




                      can anyone shed more light on this particular configuration? What does * text=auto do? What does it mean to remove it from .gitattributes? I see it fixes this problem for me, but I am not sure why it does so, and what it is really doing, and what possible issues it is possibly creating?
                      – Dennis
                      Feb 27 '14 at 18:24






                    • 6




                      @Dennis This setting helps normalize line endings, so deleting it is likely not the right answer. See this question's answer and this article. @Arrowmaster 's answer below was more helpful for me. I used git add and git commit which normalized the file and got rid of the issue.
                      – jtpereyda
                      Jun 29 '15 at 23:04








                    • 2




                      git config --global core.autocrlf input fixed it for me. Thanks.
                      – dimiguel
                      Oct 14 '15 at 15:01
















                    131














                    I had the same problem on the Mac after cloning a repo, it would assume all files have been changed.



                    After running git config --global core.autocrlf input it was still marking all files as changed. After looking for a fix I came across .gitattributes file in the home directory which had the following.



                    * text=auto


                    I commented it out and any other cloned repositories from now on are working fine. Hope this helps anyone out there.






                    share|improve this answer



















                    • 5




                      Thanks! I finally found this after spending all evening toggling core.autocrlf and apply.whitespace. This worked. Thank-you.
                      – xer0x
                      Jul 5 '12 at 8:27






                    • 5




                      The offending line in .gitattributes came from Mathias Bynen's dotfiles, in case anyone else comes across this.
                      – SeanPONeil
                      Mar 19 '13 at 14:21






                    • 28




                      can anyone shed more light on this particular configuration? What does * text=auto do? What does it mean to remove it from .gitattributes? I see it fixes this problem for me, but I am not sure why it does so, and what it is really doing, and what possible issues it is possibly creating?
                      – Dennis
                      Feb 27 '14 at 18:24






                    • 6




                      @Dennis This setting helps normalize line endings, so deleting it is likely not the right answer. See this question's answer and this article. @Arrowmaster 's answer below was more helpful for me. I used git add and git commit which normalized the file and got rid of the issue.
                      – jtpereyda
                      Jun 29 '15 at 23:04








                    • 2




                      git config --global core.autocrlf input fixed it for me. Thanks.
                      – dimiguel
                      Oct 14 '15 at 15:01














                    131












                    131








                    131






                    I had the same problem on the Mac after cloning a repo, it would assume all files have been changed.



                    After running git config --global core.autocrlf input it was still marking all files as changed. After looking for a fix I came across .gitattributes file in the home directory which had the following.



                    * text=auto


                    I commented it out and any other cloned repositories from now on are working fine. Hope this helps anyone out there.






                    share|improve this answer














                    I had the same problem on the Mac after cloning a repo, it would assume all files have been changed.



                    After running git config --global core.autocrlf input it was still marking all files as changed. After looking for a fix I came across .gitattributes file in the home directory which had the following.



                    * text=auto


                    I commented it out and any other cloned repositories from now on are working fine. Hope this helps anyone out there.







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Oct 19 '12 at 10:26

























                    answered Apr 28 '12 at 12:27









                    adnans

                    1,8992105




                    1,8992105








                    • 5




                      Thanks! I finally found this after spending all evening toggling core.autocrlf and apply.whitespace. This worked. Thank-you.
                      – xer0x
                      Jul 5 '12 at 8:27






                    • 5




                      The offending line in .gitattributes came from Mathias Bynen's dotfiles, in case anyone else comes across this.
                      – SeanPONeil
                      Mar 19 '13 at 14:21






                    • 28




                      can anyone shed more light on this particular configuration? What does * text=auto do? What does it mean to remove it from .gitattributes? I see it fixes this problem for me, but I am not sure why it does so, and what it is really doing, and what possible issues it is possibly creating?
                      – Dennis
                      Feb 27 '14 at 18:24






                    • 6




                      @Dennis This setting helps normalize line endings, so deleting it is likely not the right answer. See this question's answer and this article. @Arrowmaster 's answer below was more helpful for me. I used git add and git commit which normalized the file and got rid of the issue.
                      – jtpereyda
                      Jun 29 '15 at 23:04








                    • 2




                      git config --global core.autocrlf input fixed it for me. Thanks.
                      – dimiguel
                      Oct 14 '15 at 15:01














                    • 5




                      Thanks! I finally found this after spending all evening toggling core.autocrlf and apply.whitespace. This worked. Thank-you.
                      – xer0x
                      Jul 5 '12 at 8:27






                    • 5




                      The offending line in .gitattributes came from Mathias Bynen's dotfiles, in case anyone else comes across this.
                      – SeanPONeil
                      Mar 19 '13 at 14:21






                    • 28




                      can anyone shed more light on this particular configuration? What does * text=auto do? What does it mean to remove it from .gitattributes? I see it fixes this problem for me, but I am not sure why it does so, and what it is really doing, and what possible issues it is possibly creating?
                      – Dennis
                      Feb 27 '14 at 18:24






                    • 6




                      @Dennis This setting helps normalize line endings, so deleting it is likely not the right answer. See this question's answer and this article. @Arrowmaster 's answer below was more helpful for me. I used git add and git commit which normalized the file and got rid of the issue.
                      – jtpereyda
                      Jun 29 '15 at 23:04








                    • 2




                      git config --global core.autocrlf input fixed it for me. Thanks.
                      – dimiguel
                      Oct 14 '15 at 15:01








                    5




                    5




                    Thanks! I finally found this after spending all evening toggling core.autocrlf and apply.whitespace. This worked. Thank-you.
                    – xer0x
                    Jul 5 '12 at 8:27




                    Thanks! I finally found this after spending all evening toggling core.autocrlf and apply.whitespace. This worked. Thank-you.
                    – xer0x
                    Jul 5 '12 at 8:27




                    5




                    5




                    The offending line in .gitattributes came from Mathias Bynen's dotfiles, in case anyone else comes across this.
                    – SeanPONeil
                    Mar 19 '13 at 14:21




                    The offending line in .gitattributes came from Mathias Bynen's dotfiles, in case anyone else comes across this.
                    – SeanPONeil
                    Mar 19 '13 at 14:21




                    28




                    28




                    can anyone shed more light on this particular configuration? What does * text=auto do? What does it mean to remove it from .gitattributes? I see it fixes this problem for me, but I am not sure why it does so, and what it is really doing, and what possible issues it is possibly creating?
                    – Dennis
                    Feb 27 '14 at 18:24




                    can anyone shed more light on this particular configuration? What does * text=auto do? What does it mean to remove it from .gitattributes? I see it fixes this problem for me, but I am not sure why it does so, and what it is really doing, and what possible issues it is possibly creating?
                    – Dennis
                    Feb 27 '14 at 18:24




                    6




                    6




                    @Dennis This setting helps normalize line endings, so deleting it is likely not the right answer. See this question's answer and this article. @Arrowmaster 's answer below was more helpful for me. I used git add and git commit which normalized the file and got rid of the issue.
                    – jtpereyda
                    Jun 29 '15 at 23:04






                    @Dennis This setting helps normalize line endings, so deleting it is likely not the right answer. See this question's answer and this article. @Arrowmaster 's answer below was more helpful for me. I used git add and git commit which normalized the file and got rid of the issue.
                    – jtpereyda
                    Jun 29 '15 at 23:04






                    2




                    2




                    git config --global core.autocrlf input fixed it for me. Thanks.
                    – dimiguel
                    Oct 14 '15 at 15:01




                    git config --global core.autocrlf input fixed it for me. Thanks.
                    – dimiguel
                    Oct 14 '15 at 15:01













                    84














                    I got it. All the other developers are on ubuntu (i think), and thus have case-sensitive file systems. I, however, do not (as I'm on a mac). Indeed all the files had lowercase twins when I took a look at them using git ls-tree HEAD <path>.



                    I'll get one of them to sort it out.






                    share|improve this answer





















                    • Did they ever sort it out? I'm possibly having the same issue.
                      – Josh Johnson
                      Feb 29 '12 at 12:13






                    • 8




                      Yeah, just get someone with a case-sensitive file system to delete all but one from each set of the files which would have duplicate filenames on a case-insensitive filesystem.
                      – Sam Elliott
                      Feb 29 '12 at 22:52






                    • 1




                      Just ran into the same issue since moving from Ubuntu to Mac. Thanks, your answer hit the nail on the head. Hope the upvote pushes it to the first position. :-)
                      – chmac
                      Apr 23 '13 at 11:31






                    • 1




                      @Dirk this is why there are multiple answers. I accepted the one that applied in my case, which is not unreasonable.
                      – Sam Elliott
                      Mar 11 '16 at 17:58






                    • 1




                      This was my issue as well - case insensitive MacOS. However git ls-tree HEAD <path> showed only a single file. I was able to see the duplicate files in the GitHub.com UI, however, and also use that UI to delete one version.
                      – orion elenzil
                      Apr 17 at 19:57
















                    84














                    I got it. All the other developers are on ubuntu (i think), and thus have case-sensitive file systems. I, however, do not (as I'm on a mac). Indeed all the files had lowercase twins when I took a look at them using git ls-tree HEAD <path>.



                    I'll get one of them to sort it out.






                    share|improve this answer





















                    • Did they ever sort it out? I'm possibly having the same issue.
                      – Josh Johnson
                      Feb 29 '12 at 12:13






                    • 8




                      Yeah, just get someone with a case-sensitive file system to delete all but one from each set of the files which would have duplicate filenames on a case-insensitive filesystem.
                      – Sam Elliott
                      Feb 29 '12 at 22:52






                    • 1




                      Just ran into the same issue since moving from Ubuntu to Mac. Thanks, your answer hit the nail on the head. Hope the upvote pushes it to the first position. :-)
                      – chmac
                      Apr 23 '13 at 11:31






                    • 1




                      @Dirk this is why there are multiple answers. I accepted the one that applied in my case, which is not unreasonable.
                      – Sam Elliott
                      Mar 11 '16 at 17:58






                    • 1




                      This was my issue as well - case insensitive MacOS. However git ls-tree HEAD <path> showed only a single file. I was able to see the duplicate files in the GitHub.com UI, however, and also use that UI to delete one version.
                      – orion elenzil
                      Apr 17 at 19:57














                    84












                    84








                    84






                    I got it. All the other developers are on ubuntu (i think), and thus have case-sensitive file systems. I, however, do not (as I'm on a mac). Indeed all the files had lowercase twins when I took a look at them using git ls-tree HEAD <path>.



                    I'll get one of them to sort it out.






                    share|improve this answer












                    I got it. All the other developers are on ubuntu (i think), and thus have case-sensitive file systems. I, however, do not (as I'm on a mac). Indeed all the files had lowercase twins when I took a look at them using git ls-tree HEAD <path>.



                    I'll get one of them to sort it out.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Feb 16 '11 at 21:35









                    Sam Elliott

                    2,05621216




                    2,05621216












                    • Did they ever sort it out? I'm possibly having the same issue.
                      – Josh Johnson
                      Feb 29 '12 at 12:13






                    • 8




                      Yeah, just get someone with a case-sensitive file system to delete all but one from each set of the files which would have duplicate filenames on a case-insensitive filesystem.
                      – Sam Elliott
                      Feb 29 '12 at 22:52






                    • 1




                      Just ran into the same issue since moving from Ubuntu to Mac. Thanks, your answer hit the nail on the head. Hope the upvote pushes it to the first position. :-)
                      – chmac
                      Apr 23 '13 at 11:31






                    • 1




                      @Dirk this is why there are multiple answers. I accepted the one that applied in my case, which is not unreasonable.
                      – Sam Elliott
                      Mar 11 '16 at 17:58






                    • 1




                      This was my issue as well - case insensitive MacOS. However git ls-tree HEAD <path> showed only a single file. I was able to see the duplicate files in the GitHub.com UI, however, and also use that UI to delete one version.
                      – orion elenzil
                      Apr 17 at 19:57


















                    • Did they ever sort it out? I'm possibly having the same issue.
                      – Josh Johnson
                      Feb 29 '12 at 12:13






                    • 8




                      Yeah, just get someone with a case-sensitive file system to delete all but one from each set of the files which would have duplicate filenames on a case-insensitive filesystem.
                      – Sam Elliott
                      Feb 29 '12 at 22:52






                    • 1




                      Just ran into the same issue since moving from Ubuntu to Mac. Thanks, your answer hit the nail on the head. Hope the upvote pushes it to the first position. :-)
                      – chmac
                      Apr 23 '13 at 11:31






                    • 1




                      @Dirk this is why there are multiple answers. I accepted the one that applied in my case, which is not unreasonable.
                      – Sam Elliott
                      Mar 11 '16 at 17:58






                    • 1




                      This was my issue as well - case insensitive MacOS. However git ls-tree HEAD <path> showed only a single file. I was able to see the duplicate files in the GitHub.com UI, however, and also use that UI to delete one version.
                      – orion elenzil
                      Apr 17 at 19:57
















                    Did they ever sort it out? I'm possibly having the same issue.
                    – Josh Johnson
                    Feb 29 '12 at 12:13




                    Did they ever sort it out? I'm possibly having the same issue.
                    – Josh Johnson
                    Feb 29 '12 at 12:13




                    8




                    8




                    Yeah, just get someone with a case-sensitive file system to delete all but one from each set of the files which would have duplicate filenames on a case-insensitive filesystem.
                    – Sam Elliott
                    Feb 29 '12 at 22:52




                    Yeah, just get someone with a case-sensitive file system to delete all but one from each set of the files which would have duplicate filenames on a case-insensitive filesystem.
                    – Sam Elliott
                    Feb 29 '12 at 22:52




                    1




                    1




                    Just ran into the same issue since moving from Ubuntu to Mac. Thanks, your answer hit the nail on the head. Hope the upvote pushes it to the first position. :-)
                    – chmac
                    Apr 23 '13 at 11:31




                    Just ran into the same issue since moving from Ubuntu to Mac. Thanks, your answer hit the nail on the head. Hope the upvote pushes it to the first position. :-)
                    – chmac
                    Apr 23 '13 at 11:31




                    1




                    1




                    @Dirk this is why there are multiple answers. I accepted the one that applied in my case, which is not unreasonable.
                    – Sam Elliott
                    Mar 11 '16 at 17:58




                    @Dirk this is why there are multiple answers. I accepted the one that applied in my case, which is not unreasonable.
                    – Sam Elliott
                    Mar 11 '16 at 17:58




                    1




                    1




                    This was my issue as well - case insensitive MacOS. However git ls-tree HEAD <path> showed only a single file. I was able to see the duplicate files in the GitHub.com UI, however, and also use that UI to delete one version.
                    – orion elenzil
                    Apr 17 at 19:57




                    This was my issue as well - case insensitive MacOS. However git ls-tree HEAD <path> showed only a single file. I was able to see the duplicate files in the GitHub.com UI, however, and also use that UI to delete one version.
                    – orion elenzil
                    Apr 17 at 19:57











                    56














                    git config core.fileMode false


                    solved this problem in my case



                    https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-config.html



                    TL;DR;



                    core.fileMode



                    If false, the executable bit differences between the index and the working tree are ignored; useful on broken filesystems like FAT. See git-update-index(1).



                    The default is true, except git-clone(1) or git-init(1) will probe and set core.fileMode false if appropriate when the repository is created.






                    share|improve this answer



















                    • 2




                      This also solved my problem :)
                      – Anand Singh
                      Dec 17 '15 at 12:20










                    • solved also mine. thanks
                      – Malith
                      May 11 '16 at 6:41






                    • 1




                      But what does this do??
                      – Siwel
                      Sep 20 '16 at 22:12










                    • I would also like to know what this does, because it worked for me as well.
                      – Donato
                      Oct 17 '16 at 22:28






                    • 1




                      When i did git diff, I found that the changes were in only file mode. git picks up on chmod -R 777 . which was caused when I ran my project and this config allowed me to ignore chmod changes by git stackoverflow.com/q/1580596/6207775
                      – Ayushya
                      Jul 9 '17 at 6:02
















                    56














                    git config core.fileMode false


                    solved this problem in my case



                    https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-config.html



                    TL;DR;



                    core.fileMode



                    If false, the executable bit differences between the index and the working tree are ignored; useful on broken filesystems like FAT. See git-update-index(1).



                    The default is true, except git-clone(1) or git-init(1) will probe and set core.fileMode false if appropriate when the repository is created.






                    share|improve this answer



















                    • 2




                      This also solved my problem :)
                      – Anand Singh
                      Dec 17 '15 at 12:20










                    • solved also mine. thanks
                      – Malith
                      May 11 '16 at 6:41






                    • 1




                      But what does this do??
                      – Siwel
                      Sep 20 '16 at 22:12










                    • I would also like to know what this does, because it worked for me as well.
                      – Donato
                      Oct 17 '16 at 22:28






                    • 1




                      When i did git diff, I found that the changes were in only file mode. git picks up on chmod -R 777 . which was caused when I ran my project and this config allowed me to ignore chmod changes by git stackoverflow.com/q/1580596/6207775
                      – Ayushya
                      Jul 9 '17 at 6:02














                    56












                    56








                    56






                    git config core.fileMode false


                    solved this problem in my case



                    https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-config.html



                    TL;DR;



                    core.fileMode



                    If false, the executable bit differences between the index and the working tree are ignored; useful on broken filesystems like FAT. See git-update-index(1).



                    The default is true, except git-clone(1) or git-init(1) will probe and set core.fileMode false if appropriate when the repository is created.






                    share|improve this answer














                    git config core.fileMode false


                    solved this problem in my case



                    https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-config.html



                    TL;DR;



                    core.fileMode



                    If false, the executable bit differences between the index and the working tree are ignored; useful on broken filesystems like FAT. See git-update-index(1).



                    The default is true, except git-clone(1) or git-init(1) will probe and set core.fileMode false if appropriate when the repository is created.







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Oct 19 '16 at 10:22

























                    answered Jul 2 '15 at 14:24









                    Piotr Korlaga

                    1,445919




                    1,445919








                    • 2




                      This also solved my problem :)
                      – Anand Singh
                      Dec 17 '15 at 12:20










                    • solved also mine. thanks
                      – Malith
                      May 11 '16 at 6:41






                    • 1




                      But what does this do??
                      – Siwel
                      Sep 20 '16 at 22:12










                    • I would also like to know what this does, because it worked for me as well.
                      – Donato
                      Oct 17 '16 at 22:28






                    • 1




                      When i did git diff, I found that the changes were in only file mode. git picks up on chmod -R 777 . which was caused when I ran my project and this config allowed me to ignore chmod changes by git stackoverflow.com/q/1580596/6207775
                      – Ayushya
                      Jul 9 '17 at 6:02














                    • 2




                      This also solved my problem :)
                      – Anand Singh
                      Dec 17 '15 at 12:20










                    • solved also mine. thanks
                      – Malith
                      May 11 '16 at 6:41






                    • 1




                      But what does this do??
                      – Siwel
                      Sep 20 '16 at 22:12










                    • I would also like to know what this does, because it worked for me as well.
                      – Donato
                      Oct 17 '16 at 22:28






                    • 1




                      When i did git diff, I found that the changes were in only file mode. git picks up on chmod -R 777 . which was caused when I ran my project and this config allowed me to ignore chmod changes by git stackoverflow.com/q/1580596/6207775
                      – Ayushya
                      Jul 9 '17 at 6:02








                    2




                    2




                    This also solved my problem :)
                    – Anand Singh
                    Dec 17 '15 at 12:20




                    This also solved my problem :)
                    – Anand Singh
                    Dec 17 '15 at 12:20












                    solved also mine. thanks
                    – Malith
                    May 11 '16 at 6:41




                    solved also mine. thanks
                    – Malith
                    May 11 '16 at 6:41




                    1




                    1




                    But what does this do??
                    – Siwel
                    Sep 20 '16 at 22:12




                    But what does this do??
                    – Siwel
                    Sep 20 '16 at 22:12












                    I would also like to know what this does, because it worked for me as well.
                    – Donato
                    Oct 17 '16 at 22:28




                    I would also like to know what this does, because it worked for me as well.
                    – Donato
                    Oct 17 '16 at 22:28




                    1




                    1




                    When i did git diff, I found that the changes were in only file mode. git picks up on chmod -R 777 . which was caused when I ran my project and this config allowed me to ignore chmod changes by git stackoverflow.com/q/1580596/6207775
                    – Ayushya
                    Jul 9 '17 at 6:02




                    When i did git diff, I found that the changes were in only file mode. git picks up on chmod -R 777 . which was caused when I ran my project and this config allowed me to ignore chmod changes by git stackoverflow.com/q/1580596/6207775
                    – Ayushya
                    Jul 9 '17 at 6:02











                    51














                    I assume you are using Windows. That github page you linked has the details backwards. The problem is that CRLF line endings have been committed to the repo already and because you have core.autocrlf set to either true or input, git wants to convert the line-endings to LF so git status shows that every file is changed.



                    If this is a repo that you only want to access but have no involvement with you can run the following command to merely hide the issue without actually solving it.



                    git config core.autocrlf false





                    If this is a repo that you will be actively involved in and can commit changes to. You may wish to fix the problem by making a commit that changes all the line endings in the repo to use LF instead of CRLF and then take steps to prevent it from happening again in the future.

                    The following is taken directly from the gitattributes man page and should be preformed from a clean working directory.



                    echo "* text=auto" >>.gitattributes
                    rm .git/index # Remove the index to force git to
                    git reset # re-scan the working directory
                    git status # Show files that will be normalized
                    git add -u
                    git add .gitattributes
                    git commit -m "Introduce end-of-line normalization"


                    If any files that should not be normalized show up in git status, unset their text attribute before running git add -u.



                    manual.pdf      -text


                    Conversely, text files that git does not detect can have normalization enabled manually.



                    weirdchars.txt  text





                    share|improve this answer

















                    • 6




                      I am not using windows.
                      – Sam Elliott
                      Feb 15 '11 at 22:05






                    • 1




                      By default on non-Windows systems, core.autocrlf is set to false. So you shouldn't have even experienced this problem if it is caused by line-endings. Could you give more details on your specific setup such as what git diff shows for those files that git status says are modified, also what filesystem are you using?
                      – Arrowmaster
                      Feb 15 '11 at 22:45












                    • updated the question with answers to these questions. Will take another look over all the details in a second or two. I'm not sure what other members of the dev team are using
                      – Sam Elliott
                      Feb 16 '11 at 9:49






                    • 1




                      Thanks you Arrowmaster Answer. It helped me a lot!!! Thank you!!
                      – sree
                      Oct 25 '13 at 11:07












                    • Great!! That second part works for me! Thank you!
                      – Carlos Faria
                      Dec 20 '13 at 9:30
















                    51














                    I assume you are using Windows. That github page you linked has the details backwards. The problem is that CRLF line endings have been committed to the repo already and because you have core.autocrlf set to either true or input, git wants to convert the line-endings to LF so git status shows that every file is changed.



                    If this is a repo that you only want to access but have no involvement with you can run the following command to merely hide the issue without actually solving it.



                    git config core.autocrlf false





                    If this is a repo that you will be actively involved in and can commit changes to. You may wish to fix the problem by making a commit that changes all the line endings in the repo to use LF instead of CRLF and then take steps to prevent it from happening again in the future.

                    The following is taken directly from the gitattributes man page and should be preformed from a clean working directory.



                    echo "* text=auto" >>.gitattributes
                    rm .git/index # Remove the index to force git to
                    git reset # re-scan the working directory
                    git status # Show files that will be normalized
                    git add -u
                    git add .gitattributes
                    git commit -m "Introduce end-of-line normalization"


                    If any files that should not be normalized show up in git status, unset their text attribute before running git add -u.



                    manual.pdf      -text


                    Conversely, text files that git does not detect can have normalization enabled manually.



                    weirdchars.txt  text





                    share|improve this answer

















                    • 6




                      I am not using windows.
                      – Sam Elliott
                      Feb 15 '11 at 22:05






                    • 1




                      By default on non-Windows systems, core.autocrlf is set to false. So you shouldn't have even experienced this problem if it is caused by line-endings. Could you give more details on your specific setup such as what git diff shows for those files that git status says are modified, also what filesystem are you using?
                      – Arrowmaster
                      Feb 15 '11 at 22:45












                    • updated the question with answers to these questions. Will take another look over all the details in a second or two. I'm not sure what other members of the dev team are using
                      – Sam Elliott
                      Feb 16 '11 at 9:49






                    • 1




                      Thanks you Arrowmaster Answer. It helped me a lot!!! Thank you!!
                      – sree
                      Oct 25 '13 at 11:07












                    • Great!! That second part works for me! Thank you!
                      – Carlos Faria
                      Dec 20 '13 at 9:30














                    51












                    51








                    51






                    I assume you are using Windows. That github page you linked has the details backwards. The problem is that CRLF line endings have been committed to the repo already and because you have core.autocrlf set to either true or input, git wants to convert the line-endings to LF so git status shows that every file is changed.



                    If this is a repo that you only want to access but have no involvement with you can run the following command to merely hide the issue without actually solving it.



                    git config core.autocrlf false





                    If this is a repo that you will be actively involved in and can commit changes to. You may wish to fix the problem by making a commit that changes all the line endings in the repo to use LF instead of CRLF and then take steps to prevent it from happening again in the future.

                    The following is taken directly from the gitattributes man page and should be preformed from a clean working directory.



                    echo "* text=auto" >>.gitattributes
                    rm .git/index # Remove the index to force git to
                    git reset # re-scan the working directory
                    git status # Show files that will be normalized
                    git add -u
                    git add .gitattributes
                    git commit -m "Introduce end-of-line normalization"


                    If any files that should not be normalized show up in git status, unset their text attribute before running git add -u.



                    manual.pdf      -text


                    Conversely, text files that git does not detect can have normalization enabled manually.



                    weirdchars.txt  text





                    share|improve this answer












                    I assume you are using Windows. That github page you linked has the details backwards. The problem is that CRLF line endings have been committed to the repo already and because you have core.autocrlf set to either true or input, git wants to convert the line-endings to LF so git status shows that every file is changed.



                    If this is a repo that you only want to access but have no involvement with you can run the following command to merely hide the issue without actually solving it.



                    git config core.autocrlf false





                    If this is a repo that you will be actively involved in and can commit changes to. You may wish to fix the problem by making a commit that changes all the line endings in the repo to use LF instead of CRLF and then take steps to prevent it from happening again in the future.

                    The following is taken directly from the gitattributes man page and should be preformed from a clean working directory.



                    echo "* text=auto" >>.gitattributes
                    rm .git/index # Remove the index to force git to
                    git reset # re-scan the working directory
                    git status # Show files that will be normalized
                    git add -u
                    git add .gitattributes
                    git commit -m "Introduce end-of-line normalization"


                    If any files that should not be normalized show up in git status, unset their text attribute before running git add -u.



                    manual.pdf      -text


                    Conversely, text files that git does not detect can have normalization enabled manually.



                    weirdchars.txt  text






                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Feb 15 '11 at 21:06









                    Arrowmaster

                    7,73622323




                    7,73622323








                    • 6




                      I am not using windows.
                      – Sam Elliott
                      Feb 15 '11 at 22:05






                    • 1




                      By default on non-Windows systems, core.autocrlf is set to false. So you shouldn't have even experienced this problem if it is caused by line-endings. Could you give more details on your specific setup such as what git diff shows for those files that git status says are modified, also what filesystem are you using?
                      – Arrowmaster
                      Feb 15 '11 at 22:45












                    • updated the question with answers to these questions. Will take another look over all the details in a second or two. I'm not sure what other members of the dev team are using
                      – Sam Elliott
                      Feb 16 '11 at 9:49






                    • 1




                      Thanks you Arrowmaster Answer. It helped me a lot!!! Thank you!!
                      – sree
                      Oct 25 '13 at 11:07












                    • Great!! That second part works for me! Thank you!
                      – Carlos Faria
                      Dec 20 '13 at 9:30














                    • 6




                      I am not using windows.
                      – Sam Elliott
                      Feb 15 '11 at 22:05






                    • 1




                      By default on non-Windows systems, core.autocrlf is set to false. So you shouldn't have even experienced this problem if it is caused by line-endings. Could you give more details on your specific setup such as what git diff shows for those files that git status says are modified, also what filesystem are you using?
                      – Arrowmaster
                      Feb 15 '11 at 22:45












                    • updated the question with answers to these questions. Will take another look over all the details in a second or two. I'm not sure what other members of the dev team are using
                      – Sam Elliott
                      Feb 16 '11 at 9:49






                    • 1




                      Thanks you Arrowmaster Answer. It helped me a lot!!! Thank you!!
                      – sree
                      Oct 25 '13 at 11:07












                    • Great!! That second part works for me! Thank you!
                      – Carlos Faria
                      Dec 20 '13 at 9:30








                    6




                    6




                    I am not using windows.
                    – Sam Elliott
                    Feb 15 '11 at 22:05




                    I am not using windows.
                    – Sam Elliott
                    Feb 15 '11 at 22:05




                    1




                    1




                    By default on non-Windows systems, core.autocrlf is set to false. So you shouldn't have even experienced this problem if it is caused by line-endings. Could you give more details on your specific setup such as what git diff shows for those files that git status says are modified, also what filesystem are you using?
                    – Arrowmaster
                    Feb 15 '11 at 22:45






                    By default on non-Windows systems, core.autocrlf is set to false. So you shouldn't have even experienced this problem if it is caused by line-endings. Could you give more details on your specific setup such as what git diff shows for those files that git status says are modified, also what filesystem are you using?
                    – Arrowmaster
                    Feb 15 '11 at 22:45














                    updated the question with answers to these questions. Will take another look over all the details in a second or two. I'm not sure what other members of the dev team are using
                    – Sam Elliott
                    Feb 16 '11 at 9:49




                    updated the question with answers to these questions. Will take another look over all the details in a second or two. I'm not sure what other members of the dev team are using
                    – Sam Elliott
                    Feb 16 '11 at 9:49




                    1




                    1




                    Thanks you Arrowmaster Answer. It helped me a lot!!! Thank you!!
                    – sree
                    Oct 25 '13 at 11:07






                    Thanks you Arrowmaster Answer. It helped me a lot!!! Thank you!!
                    – sree
                    Oct 25 '13 at 11:07














                    Great!! That second part works for me! Thank you!
                    – Carlos Faria
                    Dec 20 '13 at 9:30




                    Great!! That second part works for me! Thank you!
                    – Carlos Faria
                    Dec 20 '13 at 9:30











                    32














                    Please run the following commands. That might solve the issue.



                    # Remove everything from the index.
                    git rm --cached -r .

                    # Write both the index and working directory from git's database.
                    git reset --hard





                    share|improve this answer























                    • None of the other solutions worked for me, but this one got me back up and running.
                      – rainabba
                      Oct 19 '16 at 23:45






                    • 1




                      I tried this one and it worked for me. Thank Mr. LIama!
                      – Danniel Little
                      Mar 8 '17 at 18:33










                    • This makes my repository worse. On a branch that had no changes, I had 277 after running it. I had those same changes on other branches I switched to as well. Run with caution. I just recloned by repo and have 615 files modified. :(
                      – Programmer Paul
                      Jun 13 '17 at 16:01












                    • this worked for me using git v2.7.4 with ubuntu (WSL) , Git for Windows v2.18.0.windows.1 and posh-git I have always had autocrlf false and the issue started in Git for Windows and posh-git after upgrading to 2.18.0 today
                      – Jim Frenette
                      Jun 24 at 1:33












                    • I am amazed this works. Thanks for the help. For others going down this path, the files that were seemingly modified were all .png and .bmp files managed by git LFS
                      – David Casper
                      Nov 23 at 17:01
















                    32














                    Please run the following commands. That might solve the issue.



                    # Remove everything from the index.
                    git rm --cached -r .

                    # Write both the index and working directory from git's database.
                    git reset --hard





                    share|improve this answer























                    • None of the other solutions worked for me, but this one got me back up and running.
                      – rainabba
                      Oct 19 '16 at 23:45






                    • 1




                      I tried this one and it worked for me. Thank Mr. LIama!
                      – Danniel Little
                      Mar 8 '17 at 18:33










                    • This makes my repository worse. On a branch that had no changes, I had 277 after running it. I had those same changes on other branches I switched to as well. Run with caution. I just recloned by repo and have 615 files modified. :(
                      – Programmer Paul
                      Jun 13 '17 at 16:01












                    • this worked for me using git v2.7.4 with ubuntu (WSL) , Git for Windows v2.18.0.windows.1 and posh-git I have always had autocrlf false and the issue started in Git for Windows and posh-git after upgrading to 2.18.0 today
                      – Jim Frenette
                      Jun 24 at 1:33












                    • I am amazed this works. Thanks for the help. For others going down this path, the files that were seemingly modified were all .png and .bmp files managed by git LFS
                      – David Casper
                      Nov 23 at 17:01














                    32












                    32








                    32






                    Please run the following commands. That might solve the issue.



                    # Remove everything from the index.
                    git rm --cached -r .

                    # Write both the index and working directory from git's database.
                    git reset --hard





                    share|improve this answer














                    Please run the following commands. That might solve the issue.



                    # Remove everything from the index.
                    git rm --cached -r .

                    # Write both the index and working directory from git's database.
                    git reset --hard






                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Jul 19 '17 at 8:16









                    Gene Pavlovsky

                    795713




                    795713










                    answered Apr 17 '15 at 7:50









                    kds

                    19.4k62954




                    19.4k62954












                    • None of the other solutions worked for me, but this one got me back up and running.
                      – rainabba
                      Oct 19 '16 at 23:45






                    • 1




                      I tried this one and it worked for me. Thank Mr. LIama!
                      – Danniel Little
                      Mar 8 '17 at 18:33










                    • This makes my repository worse. On a branch that had no changes, I had 277 after running it. I had those same changes on other branches I switched to as well. Run with caution. I just recloned by repo and have 615 files modified. :(
                      – Programmer Paul
                      Jun 13 '17 at 16:01












                    • this worked for me using git v2.7.4 with ubuntu (WSL) , Git for Windows v2.18.0.windows.1 and posh-git I have always had autocrlf false and the issue started in Git for Windows and posh-git after upgrading to 2.18.0 today
                      – Jim Frenette
                      Jun 24 at 1:33












                    • I am amazed this works. Thanks for the help. For others going down this path, the files that were seemingly modified were all .png and .bmp files managed by git LFS
                      – David Casper
                      Nov 23 at 17:01


















                    • None of the other solutions worked for me, but this one got me back up and running.
                      – rainabba
                      Oct 19 '16 at 23:45






                    • 1




                      I tried this one and it worked for me. Thank Mr. LIama!
                      – Danniel Little
                      Mar 8 '17 at 18:33










                    • This makes my repository worse. On a branch that had no changes, I had 277 after running it. I had those same changes on other branches I switched to as well. Run with caution. I just recloned by repo and have 615 files modified. :(
                      – Programmer Paul
                      Jun 13 '17 at 16:01












                    • this worked for me using git v2.7.4 with ubuntu (WSL) , Git for Windows v2.18.0.windows.1 and posh-git I have always had autocrlf false and the issue started in Git for Windows and posh-git after upgrading to 2.18.0 today
                      – Jim Frenette
                      Jun 24 at 1:33












                    • I am amazed this works. Thanks for the help. For others going down this path, the files that were seemingly modified were all .png and .bmp files managed by git LFS
                      – David Casper
                      Nov 23 at 17:01
















                    None of the other solutions worked for me, but this one got me back up and running.
                    – rainabba
                    Oct 19 '16 at 23:45




                    None of the other solutions worked for me, but this one got me back up and running.
                    – rainabba
                    Oct 19 '16 at 23:45




                    1




                    1




                    I tried this one and it worked for me. Thank Mr. LIama!
                    – Danniel Little
                    Mar 8 '17 at 18:33




                    I tried this one and it worked for me. Thank Mr. LIama!
                    – Danniel Little
                    Mar 8 '17 at 18:33












                    This makes my repository worse. On a branch that had no changes, I had 277 after running it. I had those same changes on other branches I switched to as well. Run with caution. I just recloned by repo and have 615 files modified. :(
                    – Programmer Paul
                    Jun 13 '17 at 16:01






                    This makes my repository worse. On a branch that had no changes, I had 277 after running it. I had those same changes on other branches I switched to as well. Run with caution. I just recloned by repo and have 615 files modified. :(
                    – Programmer Paul
                    Jun 13 '17 at 16:01














                    this worked for me using git v2.7.4 with ubuntu (WSL) , Git for Windows v2.18.0.windows.1 and posh-git I have always had autocrlf false and the issue started in Git for Windows and posh-git after upgrading to 2.18.0 today
                    – Jim Frenette
                    Jun 24 at 1:33






                    this worked for me using git v2.7.4 with ubuntu (WSL) , Git for Windows v2.18.0.windows.1 and posh-git I have always had autocrlf false and the issue started in Git for Windows and posh-git after upgrading to 2.18.0 today
                    – Jim Frenette
                    Jun 24 at 1:33














                    I am amazed this works. Thanks for the help. For others going down this path, the files that were seemingly modified were all .png and .bmp files managed by git LFS
                    – David Casper
                    Nov 23 at 17:01




                    I am amazed this works. Thanks for the help. For others going down this path, the files that were seemingly modified were all .png and .bmp files managed by git LFS
                    – David Casper
                    Nov 23 at 17:01











                    15














                    In Visual Studio, if you are using Git, you can auto generate the .gitignore and .gitattributes files. The auto generated .getattributes file has the following line:



                    * text=auto


                    This line is near the top of the file. We just needed to comment the line out by adding a # to the front of it. After doing that, things operated as expected.






                    share|improve this answer



















                    • 1




                      Thanks, been struggling with this for aaaages
                      – Andrew Berry
                      Nov 11 '15 at 16:37










                    • This was exactly my issue. Another developer had used GIT through VS instead of CLI and created this .gitattributes file.
                      – Josh Maag
                      Aug 23 '16 at 18:42
















                    15














                    In Visual Studio, if you are using Git, you can auto generate the .gitignore and .gitattributes files. The auto generated .getattributes file has the following line:



                    * text=auto


                    This line is near the top of the file. We just needed to comment the line out by adding a # to the front of it. After doing that, things operated as expected.






                    share|improve this answer



















                    • 1




                      Thanks, been struggling with this for aaaages
                      – Andrew Berry
                      Nov 11 '15 at 16:37










                    • This was exactly my issue. Another developer had used GIT through VS instead of CLI and created this .gitattributes file.
                      – Josh Maag
                      Aug 23 '16 at 18:42














                    15












                    15








                    15






                    In Visual Studio, if you are using Git, you can auto generate the .gitignore and .gitattributes files. The auto generated .getattributes file has the following line:



                    * text=auto


                    This line is near the top of the file. We just needed to comment the line out by adding a # to the front of it. After doing that, things operated as expected.






                    share|improve this answer














                    In Visual Studio, if you are using Git, you can auto generate the .gitignore and .gitattributes files. The auto generated .getattributes file has the following line:



                    * text=auto


                    This line is near the top of the file. We just needed to comment the line out by adding a # to the front of it. After doing that, things operated as expected.







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Nov 13 '15 at 19:56

























                    answered Oct 25 '13 at 14:48









                    J Adam Rogers

                    66965




                    66965








                    • 1




                      Thanks, been struggling with this for aaaages
                      – Andrew Berry
                      Nov 11 '15 at 16:37










                    • This was exactly my issue. Another developer had used GIT through VS instead of CLI and created this .gitattributes file.
                      – Josh Maag
                      Aug 23 '16 at 18:42














                    • 1




                      Thanks, been struggling with this for aaaages
                      – Andrew Berry
                      Nov 11 '15 at 16:37










                    • This was exactly my issue. Another developer had used GIT through VS instead of CLI and created this .gitattributes file.
                      – Josh Maag
                      Aug 23 '16 at 18:42








                    1




                    1




                    Thanks, been struggling with this for aaaages
                    – Andrew Berry
                    Nov 11 '15 at 16:37




                    Thanks, been struggling with this for aaaages
                    – Andrew Berry
                    Nov 11 '15 at 16:37












                    This was exactly my issue. Another developer had used GIT through VS instead of CLI and created this .gitattributes file.
                    – Josh Maag
                    Aug 23 '16 at 18:42




                    This was exactly my issue. Another developer had used GIT through VS instead of CLI and created this .gitattributes file.
                    – Josh Maag
                    Aug 23 '16 at 18:42











                    11














                    The problem might also arise from differing file permissions, as was my case:



                    Fresh cloned repository (Windows, Cygwin):



                    $ git ls-tree HEAD
                    100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
                    ↑↑↑


                    Bare remote repository (Linux):



                    $ git ls-tree HEAD
                    100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
                    ↑↑↑





                    share|improve this answer




























                      11














                      The problem might also arise from differing file permissions, as was my case:



                      Fresh cloned repository (Windows, Cygwin):



                      $ git ls-tree HEAD
                      100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
                      ↑↑↑


                      Bare remote repository (Linux):



                      $ git ls-tree HEAD
                      100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
                      ↑↑↑





                      share|improve this answer


























                        11












                        11








                        11






                        The problem might also arise from differing file permissions, as was my case:



                        Fresh cloned repository (Windows, Cygwin):



                        $ git ls-tree HEAD
                        100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
                        ↑↑↑


                        Bare remote repository (Linux):



                        $ git ls-tree HEAD
                        100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
                        ↑↑↑





                        share|improve this answer














                        The problem might also arise from differing file permissions, as was my case:



                        Fresh cloned repository (Windows, Cygwin):



                        $ git ls-tree HEAD
                        100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
                        ↑↑↑


                        Bare remote repository (Linux):



                        $ git ls-tree HEAD
                        100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
                        ↑↑↑






                        share|improve this answer














                        share|improve this answer



                        share|improve this answer








                        edited Oct 25 '15 at 15:26









                        Ayusman

                        4,3301657119




                        4,3301657119










                        answered May 14 '14 at 12:44









                        Gima

                        1,1311121




                        1,1311121























                            3














                            I had the same problem. Also with a Mac. Looking at the repo on a linux machine I noticed that I had two files:



                            geoip.dat and GeoIP.dat



                            Removed the deprecated one on the linux machine and cloned the repository again to the mac. I was not able to pull, commit, stash or pull from my copy of the repository when there were duplicates.






                            share|improve this answer


























                              3














                              I had the same problem. Also with a Mac. Looking at the repo on a linux machine I noticed that I had two files:



                              geoip.dat and GeoIP.dat



                              Removed the deprecated one on the linux machine and cloned the repository again to the mac. I was not able to pull, commit, stash or pull from my copy of the repository when there were duplicates.






                              share|improve this answer
























                                3












                                3








                                3






                                I had the same problem. Also with a Mac. Looking at the repo on a linux machine I noticed that I had two files:



                                geoip.dat and GeoIP.dat



                                Removed the deprecated one on the linux machine and cloned the repository again to the mac. I was not able to pull, commit, stash or pull from my copy of the repository when there were duplicates.






                                share|improve this answer












                                I had the same problem. Also with a Mac. Looking at the repo on a linux machine I noticed that I had two files:



                                geoip.dat and GeoIP.dat



                                Removed the deprecated one on the linux machine and cloned the repository again to the mac. I was not able to pull, commit, stash or pull from my copy of the repository when there were duplicates.







                                share|improve this answer












                                share|improve this answer



                                share|improve this answer










                                answered Oct 21 '13 at 8:17









                                user2148301

                                539143




                                539143























                                    3














                                    I wanted to add an answer more directed on "Why" this happens, because there is already a good answer on how to fix it.



                                    So, .gitattributes has a * text=auto setting, which causes this issue.



                                    In my case Files on GitHub’s master branch had rn endings. I have dialed up the settings on the repo to check-in with n endings. I don't know what git checks out though. It is supposed to check out with native endings onto my Linux box (n), but I guess it checked out the file with rn endings. Git complains because it sees the checked out rn endings that were in the repo and warns me that it will check in n settings. Hence files are "to be modified".



                                    That's my understanding for now.






                                    share|improve this answer


























                                      3














                                      I wanted to add an answer more directed on "Why" this happens, because there is already a good answer on how to fix it.



                                      So, .gitattributes has a * text=auto setting, which causes this issue.



                                      In my case Files on GitHub’s master branch had rn endings. I have dialed up the settings on the repo to check-in with n endings. I don't know what git checks out though. It is supposed to check out with native endings onto my Linux box (n), but I guess it checked out the file with rn endings. Git complains because it sees the checked out rn endings that were in the repo and warns me that it will check in n settings. Hence files are "to be modified".



                                      That's my understanding for now.






                                      share|improve this answer
























                                        3












                                        3








                                        3






                                        I wanted to add an answer more directed on "Why" this happens, because there is already a good answer on how to fix it.



                                        So, .gitattributes has a * text=auto setting, which causes this issue.



                                        In my case Files on GitHub’s master branch had rn endings. I have dialed up the settings on the repo to check-in with n endings. I don't know what git checks out though. It is supposed to check out with native endings onto my Linux box (n), but I guess it checked out the file with rn endings. Git complains because it sees the checked out rn endings that were in the repo and warns me that it will check in n settings. Hence files are "to be modified".



                                        That's my understanding for now.






                                        share|improve this answer












                                        I wanted to add an answer more directed on "Why" this happens, because there is already a good answer on how to fix it.



                                        So, .gitattributes has a * text=auto setting, which causes this issue.



                                        In my case Files on GitHub’s master branch had rn endings. I have dialed up the settings on the repo to check-in with n endings. I don't know what git checks out though. It is supposed to check out with native endings onto my Linux box (n), but I guess it checked out the file with rn endings. Git complains because it sees the checked out rn endings that were in the repo and warns me that it will check in n settings. Hence files are "to be modified".



                                        That's my understanding for now.







                                        share|improve this answer












                                        share|improve this answer



                                        share|improve this answer










                                        answered Feb 27 '14 at 18:36









                                        Dennis

                                        3,03542873




                                        3,03542873























                                            1














                                            I also just had the same problem. In my case I cloned the repo and some files were immediately missing.



                                            This was caused by the path to the file and the filename being too long for Windows. To resolve it clone the repo as close to the hdd root as possible to reduce the length of the path to the file e.g. clone it to C:AGitRepo instead of C:Users DocumentsyyyDesktopGitRepo






                                            share|improve this answer


























                                              1














                                              I also just had the same problem. In my case I cloned the repo and some files were immediately missing.



                                              This was caused by the path to the file and the filename being too long for Windows. To resolve it clone the repo as close to the hdd root as possible to reduce the length of the path to the file e.g. clone it to C:AGitRepo instead of C:Users DocumentsyyyDesktopGitRepo






                                              share|improve this answer
























                                                1












                                                1








                                                1






                                                I also just had the same problem. In my case I cloned the repo and some files were immediately missing.



                                                This was caused by the path to the file and the filename being too long for Windows. To resolve it clone the repo as close to the hdd root as possible to reduce the length of the path to the file e.g. clone it to C:AGitRepo instead of C:Users DocumentsyyyDesktopGitRepo






                                                share|improve this answer












                                                I also just had the same problem. In my case I cloned the repo and some files were immediately missing.



                                                This was caused by the path to the file and the filename being too long for Windows. To resolve it clone the repo as close to the hdd root as possible to reduce the length of the path to the file e.g. clone it to C:AGitRepo instead of C:Users DocumentsyyyDesktopGitRepo







                                                share|improve this answer












                                                share|improve this answer



                                                share|improve this answer










                                                answered Dec 13 '13 at 8:48









                                                8bitme

                                                4871718




                                                4871718























                                                    1














                                                    Edit file called: sudo gedit .git/config sudo vim .git/config



                                                    [core]
                                                    repositoryformatversion = 0
                                                    filemode = false
                                                    bare = false
                                                    logallrefupdates = true
                                                    [remote "origin"]
                                                    url = kharadepramod@bitbucket.org:DigitalPlumbing/unicorn-magento.git
                                                    fetch = +refs/heads/*:refs/remotes/origin/*
                                                    [branch "master"]
                                                    remote = origin
                                                    merge = refs/heads/master
                                                    [branch "productapproval"]
                                                    remote = origin
                                                    merge = refs/heads/productapproval


                                                    Change filemode=true into filemode = false






                                                    share|improve this answer


























                                                      1














                                                      Edit file called: sudo gedit .git/config sudo vim .git/config



                                                      [core]
                                                      repositoryformatversion = 0
                                                      filemode = false
                                                      bare = false
                                                      logallrefupdates = true
                                                      [remote "origin"]
                                                      url = kharadepramod@bitbucket.org:DigitalPlumbing/unicorn-magento.git
                                                      fetch = +refs/heads/*:refs/remotes/origin/*
                                                      [branch "master"]
                                                      remote = origin
                                                      merge = refs/heads/master
                                                      [branch "productapproval"]
                                                      remote = origin
                                                      merge = refs/heads/productapproval


                                                      Change filemode=true into filemode = false






                                                      share|improve this answer
























                                                        1












                                                        1








                                                        1






                                                        Edit file called: sudo gedit .git/config sudo vim .git/config



                                                        [core]
                                                        repositoryformatversion = 0
                                                        filemode = false
                                                        bare = false
                                                        logallrefupdates = true
                                                        [remote "origin"]
                                                        url = kharadepramod@bitbucket.org:DigitalPlumbing/unicorn-magento.git
                                                        fetch = +refs/heads/*:refs/remotes/origin/*
                                                        [branch "master"]
                                                        remote = origin
                                                        merge = refs/heads/master
                                                        [branch "productapproval"]
                                                        remote = origin
                                                        merge = refs/heads/productapproval


                                                        Change filemode=true into filemode = false






                                                        share|improve this answer












                                                        Edit file called: sudo gedit .git/config sudo vim .git/config



                                                        [core]
                                                        repositoryformatversion = 0
                                                        filemode = false
                                                        bare = false
                                                        logallrefupdates = true
                                                        [remote "origin"]
                                                        url = kharadepramod@bitbucket.org:DigitalPlumbing/unicorn-magento.git
                                                        fetch = +refs/heads/*:refs/remotes/origin/*
                                                        [branch "master"]
                                                        remote = origin
                                                        merge = refs/heads/master
                                                        [branch "productapproval"]
                                                        remote = origin
                                                        merge = refs/heads/productapproval


                                                        Change filemode=true into filemode = false







                                                        share|improve this answer












                                                        share|improve this answer



                                                        share|improve this answer










                                                        answered Oct 24 '17 at 7:02









                                                        Pramod Kharade

                                                        576620




                                                        576620























                                                            0














                                                            I copied my local repository to another folder and a bunch of modified files showed up.
                                                            My workaround was: I stashed the modified files and deleted the stash. The repository became clean.






                                                            share|improve this answer


























                                                              0














                                                              I copied my local repository to another folder and a bunch of modified files showed up.
                                                              My workaround was: I stashed the modified files and deleted the stash. The repository became clean.






                                                              share|improve this answer
























                                                                0












                                                                0








                                                                0






                                                                I copied my local repository to another folder and a bunch of modified files showed up.
                                                                My workaround was: I stashed the modified files and deleted the stash. The repository became clean.






                                                                share|improve this answer












                                                                I copied my local repository to another folder and a bunch of modified files showed up.
                                                                My workaround was: I stashed the modified files and deleted the stash. The repository became clean.







                                                                share|improve this answer












                                                                share|improve this answer



                                                                share|improve this answer










                                                                answered Apr 22 '15 at 8:26









                                                                Oleg Shvetsov

                                                                7115




                                                                7115























                                                                    0














                                                                    I found that git was treating my files (.psd in this case) as text. Setting it to a binary type in the .gitattributes solved it.



                                                                    *.psd binary





                                                                    share|improve this answer


























                                                                      0














                                                                      I found that git was treating my files (.psd in this case) as text. Setting it to a binary type in the .gitattributes solved it.



                                                                      *.psd binary





                                                                      share|improve this answer
























                                                                        0












                                                                        0








                                                                        0






                                                                        I found that git was treating my files (.psd in this case) as text. Setting it to a binary type in the .gitattributes solved it.



                                                                        *.psd binary





                                                                        share|improve this answer












                                                                        I found that git was treating my files (.psd in this case) as text. Setting it to a binary type in the .gitattributes solved it.



                                                                        *.psd binary






                                                                        share|improve this answer












                                                                        share|improve this answer



                                                                        share|improve this answer










                                                                        answered Sep 10 '15 at 21:33









                                                                        Lanny

                                                                        9,54611429




                                                                        9,54611429























                                                                            0














                                                                            I was having a similar problem and found this question.



                                                                            I was trying to do an interactive rebase, but it claimed there were some modified files, so it wouldn't let me do it right now. I tried EVERYTHING to get back to a clean repo, but nothing worked. None of the other answers helped. But this finally worked...



                                                                            git rm -rf the-folder-with-modified-stuff
                                                                            git ci -m 'WAT'


                                                                            Boom! Clean repo. Problem solved. Then I just had to drop the last commit when I did my rebase -i and finally everything was clean again.
                                                                            Bizarre!



                                                                            But I'm adding this solution here so that maybe if I ever run into this again I'll see this and try it. Thanks :D






                                                                            share|improve this answer


























                                                                              0














                                                                              I was having a similar problem and found this question.



                                                                              I was trying to do an interactive rebase, but it claimed there were some modified files, so it wouldn't let me do it right now. I tried EVERYTHING to get back to a clean repo, but nothing worked. None of the other answers helped. But this finally worked...



                                                                              git rm -rf the-folder-with-modified-stuff
                                                                              git ci -m 'WAT'


                                                                              Boom! Clean repo. Problem solved. Then I just had to drop the last commit when I did my rebase -i and finally everything was clean again.
                                                                              Bizarre!



                                                                              But I'm adding this solution here so that maybe if I ever run into this again I'll see this and try it. Thanks :D






                                                                              share|improve this answer
























                                                                                0












                                                                                0








                                                                                0






                                                                                I was having a similar problem and found this question.



                                                                                I was trying to do an interactive rebase, but it claimed there were some modified files, so it wouldn't let me do it right now. I tried EVERYTHING to get back to a clean repo, but nothing worked. None of the other answers helped. But this finally worked...



                                                                                git rm -rf the-folder-with-modified-stuff
                                                                                git ci -m 'WAT'


                                                                                Boom! Clean repo. Problem solved. Then I just had to drop the last commit when I did my rebase -i and finally everything was clean again.
                                                                                Bizarre!



                                                                                But I'm adding this solution here so that maybe if I ever run into this again I'll see this and try it. Thanks :D






                                                                                share|improve this answer












                                                                                I was having a similar problem and found this question.



                                                                                I was trying to do an interactive rebase, but it claimed there were some modified files, so it wouldn't let me do it right now. I tried EVERYTHING to get back to a clean repo, but nothing worked. None of the other answers helped. But this finally worked...



                                                                                git rm -rf the-folder-with-modified-stuff
                                                                                git ci -m 'WAT'


                                                                                Boom! Clean repo. Problem solved. Then I just had to drop the last commit when I did my rebase -i and finally everything was clean again.
                                                                                Bizarre!



                                                                                But I'm adding this solution here so that maybe if I ever run into this again I'll see this and try it. Thanks :D







                                                                                share|improve this answer












                                                                                share|improve this answer



                                                                                share|improve this answer










                                                                                answered Aug 10 at 11:09









                                                                                Thomas Aylott

                                                                                7561511




                                                                                7561511























                                                                                    0














                                                                                    For new versions of macOS this can be caused by a security feature of the OS.



                                                                                    In the repository I was working on, there was a binary file which had *.app as file type.
                                                                                    It was just some serialised data, but macOS treats all *.app files as an application and as this file was not downloaded by the user, the system deemed it insecure and added the com.apple.quarantine file attribute which makes sure the file can not be executed.



                                                                                    But setting this attribute on the file was also changing the file and it therefore showed up in the git change set without any way of reverting it.



                                                                                    You can check if you have the same problem by running $ xattr file.app



                                                                                    The solution is pretty simple, as long as you don't have to work with the file.
                                                                                    Just add *.app binary to your .gitattributes






                                                                                    share|improve this answer


























                                                                                      0














                                                                                      For new versions of macOS this can be caused by a security feature of the OS.



                                                                                      In the repository I was working on, there was a binary file which had *.app as file type.
                                                                                      It was just some serialised data, but macOS treats all *.app files as an application and as this file was not downloaded by the user, the system deemed it insecure and added the com.apple.quarantine file attribute which makes sure the file can not be executed.



                                                                                      But setting this attribute on the file was also changing the file and it therefore showed up in the git change set without any way of reverting it.



                                                                                      You can check if you have the same problem by running $ xattr file.app



                                                                                      The solution is pretty simple, as long as you don't have to work with the file.
                                                                                      Just add *.app binary to your .gitattributes






                                                                                      share|improve this answer
























                                                                                        0












                                                                                        0








                                                                                        0






                                                                                        For new versions of macOS this can be caused by a security feature of the OS.



                                                                                        In the repository I was working on, there was a binary file which had *.app as file type.
                                                                                        It was just some serialised data, but macOS treats all *.app files as an application and as this file was not downloaded by the user, the system deemed it insecure and added the com.apple.quarantine file attribute which makes sure the file can not be executed.



                                                                                        But setting this attribute on the file was also changing the file and it therefore showed up in the git change set without any way of reverting it.



                                                                                        You can check if you have the same problem by running $ xattr file.app



                                                                                        The solution is pretty simple, as long as you don't have to work with the file.
                                                                                        Just add *.app binary to your .gitattributes






                                                                                        share|improve this answer












                                                                                        For new versions of macOS this can be caused by a security feature of the OS.



                                                                                        In the repository I was working on, there was a binary file which had *.app as file type.
                                                                                        It was just some serialised data, but macOS treats all *.app files as an application and as this file was not downloaded by the user, the system deemed it insecure and added the com.apple.quarantine file attribute which makes sure the file can not be executed.



                                                                                        But setting this attribute on the file was also changing the file and it therefore showed up in the git change set without any way of reverting it.



                                                                                        You can check if you have the same problem by running $ xattr file.app



                                                                                        The solution is pretty simple, as long as you don't have to work with the file.
                                                                                        Just add *.app binary to your .gitattributes







                                                                                        share|improve this answer












                                                                                        share|improve this answer



                                                                                        share|improve this answer










                                                                                        answered Nov 21 at 8:13









                                                                                        Lukas Zech

                                                                                        19826




                                                                                        19826























                                                                                            0














                                                                                            Same issue for me. I could see several images with the same name like "textField.png" and "textfield.png" in the remote Git repo but not on my local repo, I was only able to see "textField.png" wich was not used in the project's code.
                                                                                            It turns out most of my colleagues are on Ubuntu using ext4 filesystem whereas I'm on a Mac using APFS.



                                                                                            Thanks to Sam Elliott's answer, the solution was quite simple. First I asked a colleague on Ubuntu to delete the redundant file versions with the uppercase, then commit and push on remote.



                                                                                            Then I ran the following :



                                                                                            # Remove everything from the index.
                                                                                            git rm --cached -r .

                                                                                            # Write both the index and working directory from git's database.
                                                                                            git reset --hard


                                                                                            Finally, we decided that every developer should change his Git config to prevent this to ever happen again



                                                                                            # Local Git config
                                                                                            git config core.ignorecase = true


                                                                                            or



                                                                                            # Global Git config
                                                                                            git config --global core.ignorecase = true





                                                                                            share|improve this answer





















                                                                                            • It would be better if you just upvoted @kds's answer!
                                                                                              – Elharony
                                                                                              Dec 7 at 9:59
















                                                                                            0














                                                                                            Same issue for me. I could see several images with the same name like "textField.png" and "textfield.png" in the remote Git repo but not on my local repo, I was only able to see "textField.png" wich was not used in the project's code.
                                                                                            It turns out most of my colleagues are on Ubuntu using ext4 filesystem whereas I'm on a Mac using APFS.



                                                                                            Thanks to Sam Elliott's answer, the solution was quite simple. First I asked a colleague on Ubuntu to delete the redundant file versions with the uppercase, then commit and push on remote.



                                                                                            Then I ran the following :



                                                                                            # Remove everything from the index.
                                                                                            git rm --cached -r .

                                                                                            # Write both the index and working directory from git's database.
                                                                                            git reset --hard


                                                                                            Finally, we decided that every developer should change his Git config to prevent this to ever happen again



                                                                                            # Local Git config
                                                                                            git config core.ignorecase = true


                                                                                            or



                                                                                            # Global Git config
                                                                                            git config --global core.ignorecase = true





                                                                                            share|improve this answer





















                                                                                            • It would be better if you just upvoted @kds's answer!
                                                                                              – Elharony
                                                                                              Dec 7 at 9:59














                                                                                            0












                                                                                            0








                                                                                            0






                                                                                            Same issue for me. I could see several images with the same name like "textField.png" and "textfield.png" in the remote Git repo but not on my local repo, I was only able to see "textField.png" wich was not used in the project's code.
                                                                                            It turns out most of my colleagues are on Ubuntu using ext4 filesystem whereas I'm on a Mac using APFS.



                                                                                            Thanks to Sam Elliott's answer, the solution was quite simple. First I asked a colleague on Ubuntu to delete the redundant file versions with the uppercase, then commit and push on remote.



                                                                                            Then I ran the following :



                                                                                            # Remove everything from the index.
                                                                                            git rm --cached -r .

                                                                                            # Write both the index and working directory from git's database.
                                                                                            git reset --hard


                                                                                            Finally, we decided that every developer should change his Git config to prevent this to ever happen again



                                                                                            # Local Git config
                                                                                            git config core.ignorecase = true


                                                                                            or



                                                                                            # Global Git config
                                                                                            git config --global core.ignorecase = true





                                                                                            share|improve this answer












                                                                                            Same issue for me. I could see several images with the same name like "textField.png" and "textfield.png" in the remote Git repo but not on my local repo, I was only able to see "textField.png" wich was not used in the project's code.
                                                                                            It turns out most of my colleagues are on Ubuntu using ext4 filesystem whereas I'm on a Mac using APFS.



                                                                                            Thanks to Sam Elliott's answer, the solution was quite simple. First I asked a colleague on Ubuntu to delete the redundant file versions with the uppercase, then commit and push on remote.



                                                                                            Then I ran the following :



                                                                                            # Remove everything from the index.
                                                                                            git rm --cached -r .

                                                                                            # Write both the index and working directory from git's database.
                                                                                            git reset --hard


                                                                                            Finally, we decided that every developer should change his Git config to prevent this to ever happen again



                                                                                            # Local Git config
                                                                                            git config core.ignorecase = true


                                                                                            or



                                                                                            # Global Git config
                                                                                            git config --global core.ignorecase = true






                                                                                            share|improve this answer












                                                                                            share|improve this answer



                                                                                            share|improve this answer










                                                                                            answered Nov 22 at 8:58









                                                                                            Adrian

                                                                                            847




                                                                                            847












                                                                                            • It would be better if you just upvoted @kds's answer!
                                                                                              – Elharony
                                                                                              Dec 7 at 9:59


















                                                                                            • It would be better if you just upvoted @kds's answer!
                                                                                              – Elharony
                                                                                              Dec 7 at 9:59
















                                                                                            It would be better if you just upvoted @kds's answer!
                                                                                            – Elharony
                                                                                            Dec 7 at 9:59




                                                                                            It would be better if you just upvoted @kds's answer!
                                                                                            – Elharony
                                                                                            Dec 7 at 9:59


















                                                                                            draft saved

                                                                                            draft discarded




















































                                                                                            Thanks for contributing an answer to Stack Overflow!


                                                                                            • Please be sure to answer the question. Provide details and share your research!

                                                                                            But avoid



                                                                                            • Asking for help, clarification, or responding to other answers.

                                                                                            • Making statements based on opinion; back them up with references or personal experience.


                                                                                            To learn more, see our tips on writing great answers.





                                                                                            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                                                                                            Please pay close attention to the following guidance:


                                                                                            • Please be sure to answer the question. Provide details and share your research!

                                                                                            But avoid



                                                                                            • Asking for help, clarification, or responding to other answers.

                                                                                            • Making statements based on opinion; back them up with references or personal experience.


                                                                                            To learn more, see our tips on writing great answers.




                                                                                            draft saved


                                                                                            draft discarded














                                                                                            StackExchange.ready(
                                                                                            function () {
                                                                                            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f5009096%2ffiles-showing-as-modified-directly-after-git-clone%23new-answer', 'question_page');
                                                                                            }
                                                                                            );

                                                                                            Post as a guest















                                                                                            Required, but never shown





















































                                                                                            Required, but never shown














                                                                                            Required, but never shown












                                                                                            Required, but never shown







                                                                                            Required, but never shown

































                                                                                            Required, but never shown














                                                                                            Required, but never shown












                                                                                            Required, but never shown







                                                                                            Required, but never shown







                                                                                            Popular posts from this blog

                                                                                            404 Error Contact Form 7 ajax form submitting

                                                                                            How to know if a Active Directory user can login interactively

                                                                                            TypeError: fit_transform() missing 1 required positional argument: 'X'