Git gets the file hungry every once in a while

Question

I have a recurring issue with my Git repositories. I am developing on Windows and my production site is under Linux. Several times, it happened that Git showed all files tracked as changed. I thought this was due to a conf problem or a conflict between Windows and Linux, but this morning when I checked the Linux repo it was showing all the files as modified.

To add insult to injury, both Linux repositories that I use (1 for prod, 1 for test) showed the same thing. I had no choice but to transfer all the files, since a hard reset or checkout did not make any changes to the working directory (yes, I sucks pretty much). This is the result of commit:

Created commit #######: Git, you are so mean... 1521 files changed, 302856 insertions(+), 302856 deletions(-) 

Any ideas on how to sort this the next time this happens?

Answer 1

As Bombe says, this sounds like a line ending problem. The simplest discussion of this issue I have seen is this guide on Github.

You want to install core.autocrlf on your Windows system so that Git automatically changes the line endings in CRLF when checking from the repo to the working directory and, conversely, changes all CRLF to LF when you commit files to REPO transactions:

 $ git config --global core.autocrlf true 

You can then verify that your repo has consistent line endings, either by cloning from your Linux repo, or using git reset , which checks for a new working copy that applies the new autocrlf setting to all LFs:

 $ git reset --hard HEAD 

EDIT. If Git does not recognize the file as binary, autocrlf can corrupt the file by changing what it considers CRLF or LF. If your repo includes unusual binary formatted file types, declare their conversion type explicitly in .gitattributes , as described in the manpage .

Answer 2

Sounds like a line ending problem. Check out man git -config for core.autocrlf .

Answer 3

I think the real problem you need to deal with is how the files are different, and what is the difference you expect to see?

The traditional default is that git does not change the contents of the file to git add in the repository. Later git installer windows include core.autocrlf , which takes unix to the end of the Windows line to checkout, and reverse to add to the repository.

For this reason, if you have more expected changes, you often think that git add all pending files (for example, via git add -u ).

At this stage, any cleaning / lubrication filters will be applied, and git diff --cached should give a reasonable spread.

If you have supplied files that git thinks differently but the difference is not visible, you may need to look at the raw bytes to see if there are any differences in invisible characters.

You can use a tool like hexdump .

Assuming myfile.txt has differences that are not visible, you can try something like this.

 # Extract raw versions of the differing files and hexdump to some temporary files git cat-file blob :myfile.txt | hexdump -C >myfile-stagetmp.bytes git cat-file blob HEAD:myfile.txt | hexdump -C >myfile-headtmp.bytes # Diff them. (Yes, you don't have to use git diff!) git diff --no-index myfile-stagetmp.bytes myfile-headtmp.bytes