# How Git Deals With Line Endings **Several settings govern how git handles line endings: `core.autocrlf`, `core.eol`, and `core.safecrlf`.** `core.whitespace` can be used to label various whitespace-related issues in git diff. ```console $ git config --global core.autocrlf true ``` ## `core.eol` Line ending to use in the working directory for text files. Defaults to `native`. This value is ignored if `autocrlf` is set to `true` or `input`. ## `core.autocrlf` Three settings exist: 1. **`true` is recommended for Windows. Git will convert LF endings into CRLF at checkout, and CRLF endings to LF before writing to the repository.** It's the same as designating all files as `text=auto` and setting `core.eol` to `crlf`. Use this if you want CRLF in your working directory but LF in the repository. 2. **With `input`, git will convert working tree CRLF into LF before writing to the repository. No conversions will be done at checkout** though. 3. **With `false`, no conversion is performed.** Working tree files are stored in the repository as is. ## `core.safecrlf` With any line ending conversion there's a chance of data corruption. You can safeguard against this by setting `core.safecrlf` to either `true` or `warn`. **If set, git will ensure that committing a file followed by a checkout will not change the file. If this is not the case, git will reject the file.** This will happen whenever you have a mixture of LF and CRLF. If you're dealing with a text file you'd actually want git to "corrupt" this file and fix it but **if you're dealing with a binary file that is wrongly classified as text, changing the CRLF to LF when committing will not be reversible.**