Files showing as modified directly after a Git clone

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 repository, git status shows several files as changed. Note: I haven't opened the repository 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.

I'm on a Mac, and there are no submodules in the repository itself.

The filesystem is "Journaled HFS+" filesystem on the Mac and is not case-sensitive. The files are one-line and about 79 KB 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 repository on it.

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

score 151 · Answer 1 · edited Apr 23 '19 at 20:11

151

I had the same problem on the Mac after cloning a repository. It would assume all files had 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 were working fine.

edited Apr 23 '19 at 20:11

Peter Mortensen

30,738
21
105
131

answered Apr 28 '12 at 12:27

adnans

2,259
2
15
5

5

The offending line in .gitattributes came from [Mathias Bynen's dotfiles](https://github.com/mathiasbynens/dotfiles), in case anyone else comes across this. – SeanPONeil Mar 19 '13 at 14:21
34

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
7

@Dennis This setting helps normalize line endings, so deleting it is likely not the right answer. See [this question](http://stackoverflow.com/q/170961/461834)'s answer and [this article](http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/). @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
I don't have that file `.gitattributes` on my home directory, do I need to create it manually? – Flavio Dec 21 '17 at 18:44
I fork a repo and the `.gitattributes` file is located at the root of the project. After comment it out the problem fixed except the `.gitattributes` file status become `modified`. I run `git checkout .gitattributes` to make the working directory become clean. – yohanes Apr 06 '19 at 15:44

Piotr Korlaga · Answer 2 · 2019-04-24T16:41:17.333

97

git config core.fileMode false

solved this problem in my case

https://git-scm.com/docs/git-config

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.

edited Apr 24 '19 at 16:41

answered Jul 02 '15 at 14:24

Piotr Korlaga

3,338
2
19
28

2

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

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

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 https://stackoverflow.com/q/1580596/6207775 – Ayushya Jul 09 '17 at 06:02
1

The link is broken (*"Sorry, we cannot find your kernels"*). – Peter Mortensen Apr 23 '19 at 20:19
Thanks. This was helpful. See also https://stackoverflow.com/a/32342216/470749 – Ryan Jul 06 '20 at 21:32
I ran `chmod +x` and it made my files modified for git. Your solution helped. – Eli Halych Nov 27 '20 at 13:13
Tried everything this one solved it for me - as mentioned above, a `git diff` showed every file as `old mode 100755 new mode 100644` – Kiee Jul 22 '21 at 10:14
Perfect solution. I would add also the global parameter in order to fix it globally: git config core.fileMode false --global – dimeros Jan 21 '22 at 11:52

score 96 · Accepted Answer · edited Apr 23 '19 at 20:10

96

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.

edited Apr 23 '19 at 20:10

Peter Mortensen

30,738
21
105
131

answered Feb 16 '11 at 21:35

Sam Elliott

3,870
2
19
22

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
Ah. In this case I don't believe it is the issue that I'm running into. Thanks for responding. – Josh Johnson Feb 29 '12 at 23:55
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
Same issue here. I am on osX 10.11.1 set to case insensitive because Adobe. Had to clone the repo on a Linux box, remove all but one of the filenames and re-clone on osX. – aeu Dec 27 '15 at 05:16
Not sure, if this is the only and most frequently applicable answer to the problem. – Dirk Mar 11 '16 at 09:05
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
@SamElliott, in that case I would expect a single answer to be edited to contain all possible tracks or option, or at least mention them. – Dirk Mar 16 '16 at 16:22
1

This was my issue as well - case insensitive MacOS. However `git ls-tree HEAD ` 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 '18 at 19:57
This is my root cause, I have a folder with case issue, I have to remove the folder and add/commit it again to solve. – Sunding Wei May 30 '18 at 09:28
I've created a case-sensitive APFS volume for that on my Mac. [APFS volumes can exist in the same "container" partition](https://en.wikipedia.org/wiki/Apple_File_System#Space_sharing), thus they shouldn't add a performance penalty. – Victor Sergienko Apr 15 '19 at 18:59

score 59 · Answer 4 · edited Apr 23 '19 at 20:09

I assume you are using Windows. That GitHub page you linked to has the details backwards. The problem is that CR + LF line endings have been committed to the repository 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 repository 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 repository 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 repository to use LF instead of CR + LF 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

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 09:49
This is what worked for us (`git config core.autocrlf false` was sufficient). We were fooled by the fact that the client is running on Linux (SL/RHEL), but the Linux session is initiated via x2go from a Windows host. So this may well be the most likely solution in an Win+Lin homogeneous context. — Dirk, Mar 11 '16 at 09:07

score 46 · Answer 5 · edited Jul 19 '17 at 08:16

46

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

edited Jul 19 '17 at 08:16

Gene Pavlovsky

1,515
17
14

answered Apr 17 '15 at 07:50

kds

28,155
9
38
55

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 08 '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 '18 at 01: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 '18 at 17:01

J Adam Rogers · Answer 6 · 2015-11-13T19:56:57.913

16

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.

edited Nov 13 '15 at 19:56

answered Oct 25 '13 at 14:48

J Adam Rogers

765
6
5

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

score 12 · Answer 7 · edited Oct 25 '15 at 15:26

12

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
   ↑↑↑

edited Oct 25 '15 at 15:26

Ayusman

8,509
21
79
132

answered May 14 '14 at 12:44

Gima

1,892
19
23

score 6 · Answer 8 · edited Apr 23 '19 at 20:17

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 \r\n endings. I have dialed up the settings on the repository 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 \r\n endings. Git complains because it sees the checked out \r\n endings that were in the repository and warns me that it will check in \n settings. Hence files are "to be modified".

That's my understanding for now.

Adrian · Answer 9 · 2020-07-09T07:26:03.417

6

The same issue for me. I could see several images with the same name, like "textField.png" and "textfield.png" in the remote Git repository, but not on my local repository. I was only able to see "textField.png" which 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 configuration to prevent this to ever happen again:

# Local Git configuration
git config core.ignorecase true

or

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

edited Jul 09 '20 at 07:26

answered Nov 22 '18 at 08:58

Adrian

324
2
10

It would be better if you just `upvoted` @kds's [answer](https://stackoverflow.com/a/29693353/5560399)! – Elharony Dec 07 '18 at 09:59
It seems the command-line command should not have the equal sign (`=`) because it will end up in `ignorecase = =` in the config file. – Dmytro May 15 '20 at 11:51
1

`git config --global core.ignorecase true` – YulkyTulky Jul 08 '20 at 05:03

score 3 · Answer 10 · edited Apr 23 '19 at 20:13

3

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

geoip.dat and GeoIP.dat

I 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.

edited Apr 23 '19 at 20:13

Peter Mortensen

30,738
21
105
131

answered Oct 21 '13 at 08:17

user2148301

578
1
4
4

score 1 · Answer 11 · edited Apr 23 '19 at 20:15

I also just had the same problem. In my case I cloned the repository 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 repository as close to the hard disk drive root as possible to reduce the length of the path to the file. For example, clone it to C:\A\GitRepo instead of C:\Users Documents\yyy\Desktop\GitRepo.

score 1 · Answer 12 · answered Apr 22 '15 at 08:26

1

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.

answered Apr 22 '15 at 08:26

Oleg Shvetsov

81
1
5

score 1 · Answer 13 · edited Apr 23 '19 at 20:23

1

Edit the file called .git/config:

sudo gedit .git/config

Or:

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.

edited Apr 23 '19 at 20:23

Peter Mortensen

30,738
21
105
131

answered Oct 24 '17 at 07:02

Pramod Kharade

2,005
1
22
41

This is equivalent to `git config core.Filemode false` – Guillermo Prandi Oct 08 '19 at 21:09

score 1 · Answer 14 · edited Apr 23 '19 at 20:25

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 repository, 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 repository. Problem solved. Then I just had to drop the last commit when I did my rebase -i and finally everything was clean again. Bizarre!

score 1 · Answer 15 · edited Apr 23 '19 at 20:27

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.

score 1 · Answer 16 · answered Apr 22 '21 at 14:33

1

The issue for me is that on my MacBook, my Mac was not tracking by case. I created an APFS case-sensitive "Workspace" partition. After that, I was no longer getting the status errors.

answered Apr 22 '21 at 14:33

Kyle Smith

43
5

score 0 · Answer 17 · edited Apr 23 '19 at 20:21

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

edited Apr 23 '19 at 20:21

Peter Mortensen

30,738
21
105
131

answered Sep 10 '15 at 21:33

Lanny

11,244
1
22
30

score 0 · Answer 18 · edited Apr 23 '19 at 20:31

0

Just in case it helps someone else, there can be another cause for this problem: differing versions of Git. I was using the default installed version of Git on a Ubuntu 18.04 (Bionic Beaver) box and everything was working fine, but when trying to clone the repository using Git on Ubuntu 16.04, some files were showing up as modified.

None of the other answers here fixed my problem, but upgrading the versions of Git to match on both systems did fix the problem.

edited Apr 23 '19 at 20:31

Peter Mortensen

30,738
21
105
131

answered Apr 08 '19 at 13:57

Todd Chaffee

6,754
32
41

2

It would be helpful (and interesting) to know which versions of git were not playing nice together. – jpaugh Apr 23 '19 at 20:06

score 0 · Answer 19 · answered Oct 21 '20 at 15:55

I had a related issue on MacOS.

That is, some may not realize that, though it appears that MacOS’ file system is case sensitive, it isn’t. It will store mixed case file names but, for example, consider Foo.py and foo.py to be the same file.

A colleague had created just such a scenario by making a foo.py from a Foo.py as part of a development scaffolding. (I.e., not only enforcing PEP8 module file naming conventions, but refactoring the contents significantly from the original such that we wanted to do that kind of work in parallel). When I pulled those changes, MacOS overwrote all the modifications from foo.py into Foo.py, which caused git to think I had made local changes, when I hadn't. When doing a fresh clone, git immediately claimed that Foo.py had significant changes even though it was a fresh clone.

The solution was to rename foo.py to an entirely different file name that in no way conflicted with the original. The problem went away with a fresh clone of the repository after making that change.

(There is a system configuration flag to turn on case sensitive behavior for MacOS, but it is recommended to leave it in the default setting as toggling the behavior may break things that expect the case insensitive behavior.)

Files showing as modified directly after a Git clone

19 Answers19

Contents

Linked

Related