Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization

[Avery Pennarun <apenwarr@gmail.com>]

On Fri, May 7, 2010 at 12:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> writes:
>> - An attribute called "auto-eol" is set in the repository to turn on
>>   normalization of line endings.  Since attributes are content, the
>>   setting is copied when the repository is cloned and can be changed in
>>   an existing repository (with a few caveats).  Setting this attribute
>>   is equivalent to setting "core.autocrlf" to "input" or "true".
>
> In what way is this attribute different from existing "crlf" attribute?

Mostly that it relates to the new core.eolStyle config option instead
of core.autocrlf.  Arguably you could use the same gitattribute to set
both config options, but I don't know how you'd make that respond in a
sane backwards-compatible fashion.

> It feels as if this series is fixing shortcomings of the combination of
> core.autocrlf configuration and crlf attribute while trying very hard to
> keep their shortcomings when the user doesn't say so.  What is the
> downside of making the existing "core.autocrlf" + "crlf" combination do
> what your patch wanted to do without retaining this "keep the existing
> shortcomings for backward compatibility"?

Is this even possible?  If core.autocrlf is set, then files all over
the place start getting crlf conversion, even if no attributes are set
at all.  If core.eolStyle is set, only files with the auto-eol
attribute set appropriately will experience any conversion.

Maybe the options aren't named ideally.  "core.eolStyle" might better
be named "core.nativeEol" - it tells git what the native EOL style is
on your computer / in this repository, but it doesn't tell git to *do*
anything with this information.  The problem with core.autocrlf is
that it mixes two concepts: identifying your native EOL style, and
telling git to do stuff.  The existing gitattribute can then tell git
*not* to do stuff, but almost no projects have a .gitattributes file
that does this.

>> 1. Setting core.autocrlf in your global or system configuration is a
>> pain
>
> This is a wrong thing to do to begin with, and not worth discussing.

Ha, doesn't msysgit do this by default?  It did at one point, anyway.
I use cygwin git (which doesn't because it thinks it's Unix) so I
don't know.

If this was ever the default behaviour, then it's at least not
*obviously* wrong.

The end result is that nobody really likes the current autocrlf
behaviour, though, so I'd agree that it *ends up* being wrong.  Just
as setting it on a per-checkout basis also ends up being wrong,
because it's so easy to forget.

> You
> know and your readers know that line ending convention in the repository
> data (i.e. blobs) is under project control while line ending convention in
> the working tree is end user preference.

Yes.  But the current system doesn't make it very easy to state your preference.

>> 2. Setting core.autocrlf in an individual repository would be okay
>> except that naive users will do it after they have already cloned:
>> unless core.autocrlf is set globally, the clone will have the wrong line
>> endings, and the user needs to know how to refresh it manually (rm -rf *
>> && git checkout -f).
>
> This may be a worthy goal.  But if a "auto-eol" attribute "fixes" this,
> perhaps "crlf" attribute can be taught to fix it the same way, no?

It fixes it by making the global setting actually do what people want.
 I'm not sure the existing config option can be made to work like
that.

Again, maybe it would make sense to combine a single attribute but
have two config options (and people can eventually just stop using
core.autocrlf altogether).  I suspect it might subtly break some
existing projects, though.

Have fun,

Avery