Git makes all checked out files' end of line CRLF

I am programming on mac, and I don't really understand what Git does with the end of line of my files :

I created a repository with some files in Unix format (LF end of line).

When I clone the repository that I created, all my end of lines are CRLF. Shouldn't it detect automatically that I need LF end of line ?

I have autoclrf set to true.

GIT's documentation about autoclrf is pretty hard to u开发者_开发百科nderstand :

If you simply want to have CRLF line endings in your working directory regardless of the repository you are working with, you can set the config variable "core.autocrlf" without changing any attributes.

[core]

   autocrlf = true

This does not force normalization of all text files, but does ensure that text files that you introduce to the repository have their line endings normalized to LF when they are added, and that files that are already normalized in the repository stay normalized.

The first sentence says "if you want to have all crlf", when the second sentence says that git will auto-adjust the end of lines.

In my case, it seems like Git converts everything to CRLF and leaves it like that when I try to clone.

The gitattributes manpage is poorly laid out. In a later section, you'll find:

The core.eol configuration variable controls which line endings git will use for normalized files in your working directory; the default is to use the native line ending for your platform, or CRLF if core.autocrlf is set.

So, unless you've specified core.eol, you'll end up with lines terminated by CR+LF characters regardless of whether you're using Apple Mac OS X, Microsoft Windows, or Ubuntu Linux.

From your question:

The first sentence says "if you want to have all crlf", when the second sentence says that git will auto-adjust the end of lines.

It's important to note that there are two directions of adjustment that get performed when core.autocrlf is set to true:

• CR+LFs will become LFs in your repository/repositories. That is to say, the commit files and repository back-end will have LFs at the end of lines in text files. This keeps things consistent in your commit history, making diffs/comparisons easier if one of your coworkers' IDEs decides to magically convert your LFs to CR+LFs (who wants to see that in their diff?). You'll save a few bytes of hard drive space as well, I suppose.
• LFs will become CR+LFs in your working directory. In your checked out file system, any new text file will have lines ending in CR+LF once git touches it. This will happen even if the file had lines ending in plain LFs when you first created it.

The first thing you'll want to do is to unset core.autocrlf or set it to false. If you then want checked out text files to conform to the user's OS-preferred line endings, regardless of how they were created, just add this to your .gitattributes:

* text=auto

Alternatively, if git's not good at guessing which of your files are text, you could declare a specific extension to undergo this two-way normalization:

*.ext text

(where ext is the file extension in question)

When you set core.autocrlf to true, Git converts line endings to LF when committing to the repo, but writes out files to the working tree using the line endings appropriate for your platform settings (LF on Mac/Unix/Linux, CRLF on Windows).

Yes, you should see CRLF in your working tree on Windows when autocrlf is set to true, which includes if you're browsing through the explorer. If you push to a Linux repo, you should see that all your files end correctly with LF.