4

I've been trying a lot of different configurations to try to stop Git from inserting CRs (carriage returns). I have a local file that has LF (not CRLF) line endings in the source repo:

$ cat -vT  Source/watchr.bat
echo OFF
echo ==========================================================
echo ==========================================================
echo The "watchr" command is deprecated.
echo The new command is sidekick.bat
echo " _
echo "| |
echo "| |_ _   _ _ __   ___

Note: no ^M, so there are no CRs in there.
This is one of about 80 files, so a commit will create massive needless churn in the Git history.

Now look at the output from git diff :

$ gd -R Source/watchr.bat
+echo OFF^M
+echo ==========================================================^M
+echo ==========================================================^M
+echo The "watchr" command is deprecated.^M
+echo The new command is sidekick.bat^M
+echo " _                      ^M
+echo "| |                    ^M
+echo "| |_ _   _ _ __   ___ ^M

Argh, ^M on every line. Why? How?

The settings :

$ git config --global core.autocrlf
true

$ git config  core.autocrlf
false

$ cat -vT .gitattributes
# Set default behavior to automatically normalize line endings.
* text=

Changing the settings to input (or false) and auto (.gitattributes) has no effect.
Git still wants to insert a CR into the watchr.bat file.
The .gitconfig in my home directory also has autocrlf = true.

How do I stop Git from doing this?

Platform: Git version 1.9.5.msysgit.0, Windows 7.

jcollum
  • 43,623
  • 55
  • 191
  • 321
  • @Henke https://stackoverflow.com/a/27909336/30946 – jcollum Oct 18 '22 at 22:25
  • Interesting. As I read [your answer](https://stackoverflow.com/a/27909336), you suggest removing the `.gitattributes` file altogether. This is in contrast with [this answer](https://stackoverflow.com/a/10855862) and [this answer](https://stackoverflow.com/a/38677770), which both _recommend_ using `.gitattributes`. ~ * ~ * ~ For anyone coming here (possibly including my future self) who has the time to experiment, I would suggest replacing `* text=auto` with [`* -crlf`](https://stackoverflow.com/a/27370303) in `.gitattributes` to see what happens. – Henke Oct 19 '22 at 12:52
  • I haven't worked in Windows in close to a decade so my experience is very outdated. Maybe it's different now. This question is almost 8 years old. – jcollum Oct 20 '22 at 20:17
  • As far as I'm concerned [this](https://stackoverflow.com/a/38017715) is an accurate answer to your question. Just like `dos2unix`, Git can only **guess** whether a file is a text file or not. Both tools make wrong guesses from time to time. Maybe that's more or less what you write in your answer? (Windows being bad at guessing from a file's content what type it has.) – Henke Oct 25 '22 at 16:01

2 Answers2

3

You should try:

git config --global core.autocrlf false

(That is what I recommend in "Git on Windows (msysgit) - Unix or DOS line termination")

Check also the local config:

git config core.autocrlf false

Make sure you don't have a .gitattribute with a core.eol directive which could also add \r\n eol.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

The solution to this was to eliminate .gitattributes. I had tried commenting out * text=auto in .gitattributes but that apparently wasn't "seen" by git. My coworker eliminated that file, pushed and then I pulled it and suddenly the "add a bunch of CRs everywhere" behavior went away.

I looked for a way to get git to see the newly changed .gitattributes (the local edits I made). Couldn't find any git command that would do that, so I had to assume git would check that file anytime it did a diff. Seems that that is not the case.

Perhaps this is a bug in git on Windows (since file watchers are dicey in Windows).

jcollum
  • 43,623
  • 55
  • 191
  • 321