----- Original Message -----
From: Richard Smith
Sent: Wednesday, May 28, 2014 4:49 PM
Subject: [git-users] .gitattributes eol=crlf behavior
We have some source files that are shared among windows/linux/macos. One of
the IDE's (Keil ARM) doesn't have a setting to use LF as a eol. It preserves
the original eol when the file is mixed eol but any line that you change ends
up CRLF. We found the best solution for our workflow was to disable
normalization and use a formatter to manually normalize the eol to crlf
To date we have been using 'astyle' to set all eol to crlf. It's run prior
to commits to set the eol and do some other formatting cleanup.
Recently I've learned about the .gitattributes file. Even though we still
would use astyle for formatting I thought I would play with setting the
eol=crlf for those files.
If I set eol=crlf for the *.[ch] in the source directory git diff sees them
as changed but I don't understand why. The eol is already crlf. If turn off
the .gitattributes then the diffs go back to clean.
Any idea what git diff is thinking is different or some suggestions on how to
find out? Its not obvious from the diff output. If I use difftool kdiff3
reports the files are binary equal.
The EOL normalisation offereings in Git can be highly confusing, because of
backward compatibility options. IIUC the 'input=' option is the older style,
Also the settings, and the discussion around them, are spread over a few
different man pages. Have a look in both the git attributes and git config
pages (various places)
Finally, the EOL values that are baked into the history may not be what you
have been led to believe because of some default normalisation you have. Try
git cat-file to check.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.