2

A few days ago, I accidentally changed the line endings of some file, and committed the change. (Was CRLF, is now LF by mistake.) I still don't know if this was my editor being too clever, or perhaps git being too clever. (Actually I suspect it's git, based on my experiences trying to undo this.) Either way, it's done and I'd like to fix it. I thought I could just change the line endings in my editor, then do a commit with just the line ending change. Git refused, claiming I didn't change anything. So I added a dummy change as well, but it then committed the dummy change but also transformed the line endings, so they are still LF. Possibly relevant git settings:

C:\Users\ZKZ4PL2\eqs\hot-connect>git config core.eol

C:\Users\ZKZ4PL2\eqs\hot-connect>git config core.autocrlf
input

Any ideas?

Mark VY
  • 1,489
  • 16
  • 31
  • 1
    This might be useful? https://stackoverflow.com/questions/27810758/how-to-replace-crlf-with-lf-in-a-single-file – GregHNZ Aug 05 '19 at 02:10
  • Might, but not obvious how. What bothers me most right now is that git isn't doing what I expect, which means I'm more confused than I thought. Since autocrlf is set to `input` then according to the git docs "This variable can be set to *input*, in which case no output conversion is performed". So what's going on? – Mark VY Aug 05 '19 at 02:32
  • 1
    It's best (my opinion!) to keep autocrlf=false safecrlf=true and all relevant text files (eg *.c) explicitly text in gitattributes. [See](https://stackoverflow.com/a/31283731/3700414) Though once you have a messed up repo its more trouble – Rusi Aug 05 '19 at 06:25
  • 1
    The git devs themselves [discussing](http://git.661346.n2.nabble.com/core-autocrlf-considered-half-assed-td4684075.html) that autocrlf is broken. – Rusi Aug 05 '19 at 06:54
  • Wow. The docs do not even MENTION that "false" is a valid value for this variable; they only mention "true" and "input", and it says that "no output conversion is performed" it it's input, which is apparently super-misleading. The apparently the real way to tell git to leave my files alone is "false". Thank you! – Mark VY Aug 05 '19 at 13:40
  • 1
    @MarkVY There are also [these commands](https://stackoverflow.com/questions/17195861/undo-git-update-index-assume-unchanged-file) for cleanup after making a mess – Rusi Aug 05 '19 at 16:49
  • Neat! Probably wouldn't have helped here though. – Mark VY Aug 06 '19 at 23:36

2 Answers2

2

First, set core.atocrlf to false, in order to avoid any automagic eol transformation by Git.

 git config --global core.autocrlf false

Second, check any .gitattributes files, for core.eol directives in it.

If you have none, then changing EOL in your editor should be picked up on git add.

staafl
  • 3,147
  • 1
  • 28
  • 23
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • The docs don't even mention that "false" is a valid setting. Sigh. – Mark VY Aug 05 '19 at 13:42
  • 1
    @MarkVY I understand. I have been advocating/mentioning that "false" value those past ten years: https://stackoverflow.com/search?tab=newest&q=user%3a6309%20core.autocrlf%20false. August 2009: https://stackoverflow.com/a/1250133/6309 – VonC Aug 05 '19 at 14:18
  • Ten years! I wonder how much of that would have been prevented if the docs mentioned this option... – Mark VY Aug 06 '19 at 23:42
1

The reason Git doesn't see any changes is because it applies the autocrlf transforms before comparing the file to the previous revision.

The best policy for line ending management is to disable autocrlf and friends and manage your files manually, unless you have very specific requirements, especially if you have files that need to be in CRLF, since Git doesn't have an option for 'commit files as CRLF', only 'check out files in CRLF'. There are several scenarios in which Git can get confused or cause unexpected results (e.g. downloading the file directly from GitHub etc will download it as LF, changing settings after a file was committed can lead to uncommittable changes, etc).

autocrlf input means Git will convert CRLF to LF on committing, which is rather misleading (calling it autolf would be more appropriate in this case).

staafl
  • 3,147
  • 1
  • 28
  • 23