On Tue, 2010-08-03 at 19:56 -0400, Jay Soffian wrote:
> On Sat, Jul 31, 2010 at 2:32 AM, Walter Bright <boost@xxxxxxxxxxxxxxx> wrote:
> > So I'm lost again. If the version in the repository is always converted to
> > LF, then why do I need to set autocrlf=input ?
>
> Let's start over. :-)
>
> Before git-1.7.2, EOL conversion was rather insane. It's fixed in
> 1.7.2, so I'm going to start by explaining what happens with that
> version and later.
>
> Option 1 (text/eol attributes):
>
> - Normally git will perform no EOL conversion. Files are committed
> into the repo exactly as you see them in your checkout.
>
> - To have git perform EOL conversion, you need to either explicitly
> tell it which files are text, or let it autodetect. You normally do
> this via the .gitattributes file using:
>
> <pattern> text
>
> or
>
> * text=auto
>
> In the former case, you're telling git explicitly which files are
> text. In the latter case, you're telling git to do its best to detect
> which files are text.
>
> Files which are explicitly tagged as text, or auto-detected as text,
> will have their EOLs converted to LF on check-in, and converted to
> core.eol on check-out. core.eol defaults to "native" which means LF on
> Unix and CRLF on Cygwin, but you can explicitly set it to "lf" or
> "crlf" if you desire.
>
> Certain files you may wish to specify their EOL in the working copy
> explicitly. You do this with the eol attribute. e.g.:
>
> <pattern> eol=crlf
> <pattern> eol=lf
>
> Files which are tagged with eol={crlf,lf} are implicitly text, and
> will have their EOLs converted to LF on check-in, and converted to the
> specified EOL on check-out.
>
> Okay, so that's how you ensure that certain files have LFs in the
> repo, and the desired EOL in the working-copy.
>
> Option 2 (core.autocrlf):
>
> With core.autocrlf=true, any files in the repo that git detects as
> text and which already have LF EOLs will have their EOLs converted to
> CRLF on check-out. Also, any additions to these files, or any new
> files that git detects as text, will have their EOLs converted to LF
> on check-in.
>
> In this way, core.autocrlf=true is similar to "* text=auto", however
> it does not affect any files in the repo which already have CRLF EOLs.
>
> AFAIK, there's no reason to set core.autocrlf=true on Unix. You'd
> typically only set it under Windows.
>
> I'm going to stop here as I think these are the only options that make
> sense with 1.7.2 and above. If you want me to explain your options
> using earlier versions of git, I can try, but it's even more
> confusing.
>
> j.
If it is accurate (and I have no way of knowing, since I've never
understood the ins-and-outs before), then that was the best, most
straightforward, most complete, least confusing description of
core.autocrlf, eol={crlf,lf}, and text=auto that I have ever read. I
want this post re-formatted and included in the docs :)
For completeness, would you mind explaining the "old way" too, and
include a note on oddities such as "git says my entire working copy has
changed, but reset --hard does nothing"? I just feel like I'm closer
than I've ever been to understanding the whole mess.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
-- Will
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html