0

I need to update some files for a pull request so that they have matching line separators to the rest of the project. I've changed these files from LF to CRLF in notepad++ (couldn't figure out how to do it in intellij), now I'm trying to commit this change - and nothing else.

No matter how I try to commit and push the changes - i get 'nothing to commit'. Intellij seemed to notice a difference at first since when I right click and commited the repo it selected those files for committing - then the commit failed with the same error.

Boby Gandhi
  • 15
  • 6
  • You probably have configured Git to mess with line endings. If you do this—if you tell Git *please change my line endings when I put files into the repository and take them out of the repository* —it will do exactly that. The in-repository format, storing files inside commits in a form you *can't* see, "prefers" LF-only line endings. The out-of-the-repository format, where you can actually work with your files, uses whatever format you tell Git to use (CRLF, or LF-only). That way you don't have to *commit a change*, you just get the files in your preferred format when you work with them. – torek Apr 27 '20 at 19:15
  • If you want to work this way—i.e., have Git convert the files to your preferred setting when you have Git get them out of a commit—you just need to tell Git what your preferred setting is. **Do not use `core.autocrlf` to do this** as that tells Git: "guess what I prefer" and Git may guess wrong. Use a `.gitattributes` file, where you list which settings you prefer for each file, so that Git does not have to guess. – torek Apr 27 '20 at 19:16
  • If you want to work in a way where Git itself never messes with the line endings, **do not use `core.autocrlf`** as that turns on the "mess with line endings" settings. So either way, never use `core.autocrlf`. – torek Apr 27 '20 at 19:18
  • Note, by the way, that these are not really line *separators*. These are line *terminators*. The key difference is that the last line should have a line terminator as well. Git is OK with you leaving one out, and many or most other programs on your computer are OK with that too, but it's usually smarter to make sure the last line ends with a line terminator too, so that you don't have to add one later if you add another line. – torek Apr 27 '20 at 19:21

1 Answers1

1

It sounds like in this case you've turned on core.autocrlf. This is the intended and proper way to work on Windows, since it stores LF endings in your repository and converts them to CRLF if you're on Windows. However, it does mean that Git doesn't view a change of line endings as a change that can be committed, since the line endings in the repository are LF either way.

If you are completely, absolutely certain that your codebase will never be used on a non-Windows system and will never be used by anybody using the Windows Subsystem for Linux, then you can turn that flag off, and Git won't change your line endings, so you'll store CRLF (or more accurately, whatever line endings you used) in the repository. However, if you have users using macOS, Linux, or WSL, you will make them very cross with you if you do this, and then you'll likely have dueling line ending wars in your repository.

If instead you need your line endings for a particular set of files to always be checked out with a particular sequence (e.g., you have a batch file and CMD can't deal with LF-only endings), then you'd add an entry into your .gitattributes file that marks them appropriately:

*.bat eol=crlf

Similarly, if you have shell scripts that always must use LF endings, you can write this:

*.sh eol=lf

These aren't designed for preferences or cross-platform compatibility, but instead where the file is literally broken and can't ever work if it has the wrong line endings. If the problem is just an editor (even an editor that everyone uses) or a compiler, let folks use core.autocrlf to fix the problem on their systems.

bk2204
  • 31,903
  • 3
  • 22
  • 39