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