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

Eyvind Bernhardsen [off-list ref] 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?

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"?

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.  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.

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?