On Fri, May 7, 2010 at 6:14 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 7 May 2010, Linus Torvalds wrote: >> IOW, if you really want to say "do automatic crlf for this set of >> paths", the natural syntax for that would be >> >> * crlf=auto > > Btw, since we're discussing this, I do think that our current "crlf=input" > syntax for .gitattributes is pretty dubious. > > I don't really see why it should be a path-dependent thing on whether you > do crlf conversion on just input or on checkout too. Me neither. However, in the name of sanity, it sure would be great to have the global configuration options exactly parallel the per-project and per-file configuration options. From that point of view, 'input' exists just to keep things nice and symmetrical. And considering how complicated this discussion already is (compared to what a simple concept CRLF conversion is), that's probably worth something in itself. Part of the confusion comes from the way the options are currently declared. set vs. unset vs. unspecified vs. "input" vs. "auto" for an option named "crlf" is just very, very, unfriendly. None of the words *mean* anything. Maybe we should rethink this from the top. Imagine that we currently have no crlf options whatsoever. What *should* it look like? I suggest the following: Config: core.eolOverride = lf / crlf / auto / binary / input core.eolDefault = lf / crlf / auto / binary / input Attribute: eol = lf / crlf / auto / binary / input If eolOverride is not "auto" or unspecified, we ignore eolDefault or any attributes. If the attribute is not "auto" or unspecified, we ignore eolDefault. For all entries, unspecified is equivalent to "auto". Of course the eol attribute could be named "crlf", but that might not increase the sanity as much as we would like. And "input" means "auto, but strip CR when committing." Or maybe the problem is that it doesn't belong here at all: maybe it should be an entirely separate attribute that takes effect whenever the eol attribute/config resolves to "auto." Or maybe I'm just not thinking about it the right way? Avery -- 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