On 7. mai 2010, at 18.33, Junio C Hamano wrote: > Eyvind Bernhardsen <eyvind.bernhardsen@xxxxxxxxx> 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? 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. >> 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 :) >> 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 -- 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