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

On 7. mai 2010, at 18.33, Junio C Hamano wrote:

Eyvind Bernhardsen [off-list ref] writes:

quoted

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

Avery and Linus have covered this quite well, but I think I can use "crlf" instead of inventing a new attribute.  New patch series to come.

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

I think keeping the existing shortcomings is partly necessary because I don't want to break any existing repositories by changing the meaning of "core.autocrlf=input" and "core.autocrlf=true".

I also like "core.eolStyle" because I want a config setting that explicitly says "crlf" or "lf" rather than forcing the user to remember what "true" and "input" mean.  The new series will keep core.eolStyle.

I would like to have a boolean "core.autocrlf" that uses "core.eolStyle" instead of implying anything about line endings in the working directory, but I'm not sure if that is possible without breaking anybody's setup.

quoted

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.

I think it's worth mentioning because git doesn't currently enforce line ending normalization on a per-project basis, which is what I'm trying to rectify.  Also, the default setting in msysgit is "core.autocrlf=true", but I guess you disagree with that default :)

quoted

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?

Yes.  And it shall!
-- 
Eyvind