Configure git to always use LF line endings in the working directory

[davidanthoff]

If I understand git correctly, then this patch means that a) git will try to automatically detect whether a file is a text file (the default in any case) and then b) for all text files always use LF line endings in the working directory, even on Windows, even if there is a global setting core.eol crlf configured.

Hopefully this patch would change nothing on Mac and Linux systems. On Windows, it does mean that if I do a git clone, everything will be checked out with LF line endings, which is good, because the build fails otherwise :)

This enables the following scenario: one can clone julia and use git from a Windows environment that uses the default git configuration for line endings. And then one can compile julia in WSL. And all of that works in the /mnt/c locations. Being able to use git from the Windows environment is nice in this case because one can e.g. use the built in git in VS Code.

Someone with more git foo should carefully think this patch through, though, before it gets merged, I'm not really an expert on this.

EDIT: Oh, and I do think that this section could be removed if this patch here gets merged.

[Keno]

Presumably there was a reason why we didn't want to do this to patch files?

[vtjnash]

yeah, we had patch files with mixed eol characters (because we need to exactly match the source file)

[davidanthoff]

I think this removed line means that patch files were treated as binary files, so their line endings were never modified. I think making sure that they are always checked out with LF line endings (this PR) achieves the same goal. @maleadt, you introduced the line here, do you think the PR here subsumes your configuration?

[davidanthoff]

Alright, I only saw @vtjnash's comment after I had submitted mine. I've now changed the PR here to keep the special handling for patch files, certainly no harm in that.

[davidanthoff]

Bump, anything else that needs to be done here?

[StefanKarpinski]

@Keno, you approved... merge if this seems right to you.

[vtjnash]

EDIT: Oh, and I do think that this section could be removed if this patch here gets merged.

I think that section is equivalent to “* -text” (That is, treat all files as binary and never alter them on checkout or checkin)

[davidanthoff]

I think with the now current setting, if you edit something in your workspace and introduce a CRLF, it would store the file properly with just LF in the git repo, whereas a blanket binary treatment wouldn't?

[vtjnash]

That could make it hard to properly store files that are are expected to contain CRLF (of which I suppose #28241 (comment) is a complete list), since now git may choose to silently corrupt them. I agree that's true, I just can usually avoid using any editors that can't handle EOL correctly – even notepad.exe can finally do that.

[davidanthoff]

Hm, that is weird. I have a hard time imagining that git would misdetect a png file as a text file...

[vtjnash]

According to that git commit fix, "text=auto" used to mean "interpret all files as text"

[davidanthoff]

Ah, yes... so is it reasonable to ask everyone to use a git version >=2.10? If not, we would probably have to undo this commit... And maybe just go to declaring everything binary?

[ararslan]

so is it reasonable to ask everyone to use a git version >=2.10?

FWIW that isn't even available for my primary system (Elementary OS, which is basically Ubuntu 16.04).

[StefanKarpinski]

I think we've got to undo this change. Insisting on a super-recent git seems impractical.

[ararslan]

Reverted in #28280.