Git diff too much wrong changes

Question

Im using a windows system to push my changes to a git linux server, where users commit with macOS, could this be the problem of invalid diff changes? changes which are not changes are displayed as deleted and later on re-added as new somehow. im using sublime and also tryed netbeans with the same behaviour...

Possible duplicate of [git-diff to ignore ^M](https://stackoverflow.com/questions/1889559/git-diff-to-ignore-m) — LuFFy, Jun 20 '17 at 11:09

score 0 · Answer 1 · answered Jun 20 '17 at 11:00

Windows and *nix based operating system use different line ending character in files. In your case you are adding the Windows Carriage return character in your file and on MacOSX they are removed.

On your Sublime you can change the line ending character on save to match the MacOSX's line ending . See is there a way to convert files line ending on saving. This way you will not see these changes.

You could also instruct git to automatically do the conversion with the core.autocrlf config. See GitHub dealing with line endings

LuFFy · Answer 2 · 2017-06-20T14:19:48.767

0

GitHub suggests that you should make sure to only use \n as a newline character in git-handled repos. There's an option to auto-convert:

$ git config --global core.autocrlf true

Of course, this is said to convert crlf to lf, while you want to convert cr to lf. I hope this still works …

And then convert your files:

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

# Re-add all the deleted files to the index
# You should get lots of messages like: "warning: CRLF will be replaced by LF in <file>."
$ git diff --cached --name-only -z | xargs -0 git add

# Commit
$ git commit -m "Fix CRLF"

As Per Git Config Manual

core.autocrlf

Setting this variable to "true" is almost the same as setting the text attribute to "auto" on all files except that text files are not guaranteed to be normalized: files that contain CRLF in the repository will not be touched. Use this setting if you want to have CRLF line endings in your working directory even though the repository does not have normalized line endings. This variable can be set to input, in which case no output conversion is performed.

edited Jun 20 '17 at 14:19

answered Jun 20 '17 at 11:10

LuFFy

8,799
10
41
59

There are three different line endings, but Git only provides two of them (???). Windows use `CRLF`, Linux uses `LF` and OS X use `CR`. We have recipes in our makefile to normalize line endings since Git does not seem to do it. – jww Jun 20 '17 at 14:05
Setting this variable to "true" is almost the same as setting the text attribute to "auto" on all files except that text files are not guaranteed to be normalized: files that contain CRLF in the repository will not be touched. Use this setting if you want to have CRLF line endings in your working directory even though the repository does not have normalized line endings. This variable can be set to input, in which case no output conversion is performed. – LuFFy Jun 20 '17 at 14:09
I have four machines from OS X from 10.4 through 10.10. (My testing environment also includes Fedora 1 with GCC 3 and Windows XP with Visual C++ 6.0). – jww Jun 20 '17 at 14:10
@jww, Cool, Now Copy your repo to different folder, try to run given commands & check whether it worked or not. – LuFFy Jun 20 '17 at 14:18
Here's one you may be able to lend your expertise: [Can I have Mac, Windows, and linux share a git repo without line ending horror?](https://stackoverflow.com/q/44726068/608639) – jww Jun 23 '17 at 18:18

score 0 · Accepted Answer · answered Jul 11 '17 at 14:13

0

The remote repo has mixed cr/lf lineendings, thought it was unix, now i just set the original lineending if it happens again.

answered Jul 11 '17 at 14:13

jwetzel

3
1
4

Git diff too much wrong changes

3 Answers3