On Sun, May 9, 2010 at 6:42 AM, Eyvind Bernhardsen
<eyvind.bernhardsen@xxxxxxxxx> wrote:
> I guess I should nail my flag to the mast: Here's what I would have done, with the benefit of plenty of hindsight, had we not had core.autocrlf, and also what I think we should do to approach that ideal.
>
> Please don't get hung up too much on the names, they were chosen to not match anything suggested so far so that I can refer back to them unambiguously.
>
> My user interface would have been:
>
> - an attribute "eolconv" that enables or disables line ending conversion
> - a config variable "core.eolconv" that sets "eolconv" for all files where it is unset
> - a config variable "core.localeol" that decides whether LF or CRLF is preferred
>
> This provides the means to enable normalization on a per-project ("eolconv") or per-repository ("core.eolconv") basis, and allows the user to override the platform native line ending when normalization is in effect.
>
> [...]
>
> My current thinking on how to change my series now runs along these lines:
>
> - keep the current "crlf=auto" change
> - rename "core.eolStyle" to "core.localcrlf"
> - add a "core.crlf" that sets the "crlf" attribute on paths where it isn't explicitly configured
> - keep "core.autocrlf" for backwards compatibility, but make "core.autocrlf=input" and "core.autocrlf=true" complain if they are in conflict with the other config settings.
Bah. I think relegating the old names to "deprecated, for
compatibility" is absolutely the right thing to do. Is there a use
case where the existing crlf setup is preferable? If not, why not just
mark them as deprecated in the documentation and say "see ..."
pointing to the new functionality and use the new names as you
suggest.
$0.02. :-)
j.
--
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