What harm can it do to set autocrlf = input on windows?

Viewed 865

The reason I'm asking this is I personally feel that setting autocrlf = input on windows makes a lot of sense, however, I googled around and didn't find anybody recommending it. It seems people are usually debating between true and false and * text=auto.

So, on Windows, I don't use notepad.exe (which can't handle LF), I always use a code editor. I believe notepad users in this world and git users in this world are different people, so rendering LF properly is not a concern.

By now I have set autocrlf = input for over a year, and haven't had issues. I personally feel it's neat, because it avoids all the back and forth conversions by git, feels safer than true or auto.

I worry if I'm doing something bad. Is there some potential dangers waiting for me?

2 Answers

I'm not sure what your question really is. You seem to have copied your "understanding" of what the autocrlf=input setting does directly from the documentation; so you know what it does, and you know what you want it to do.

The harm would be getting that behavior when it isn't the desired behavior; if you know it's the desired behavior, then what's the issue?

Although @LightBender already answered the question in comment, you can always make some experiments by yourself:

  1. In an empty directory, create a new bare repo: git --bare init

  2. In two other directories, do git clone <path to bare repo>

  3. In one of them set: git config core.autocrlf input
    In the second one git config core.autocrlf false

  4. Create sample text file containing multiple lines of text and push it into bare repository.

  5. Change line ending in first clone and try to push your changes -git will be unable to register any changes and changed line ending will remain locally.

  6. Also alter single line of text in second clone to provoke a conflict.

  7. Observe conflicted file. You can see whole file marked as conflict instead of single affected line.

Another exercise would be to do the same in reverse order.

So in short: to prevent from any potential problems, simply make sure all your contributors use the same line ending convention when pushing into remote.

Related