On 9. mai 2010, at 01.42, Dmitry Potapov wrote: > On Sat, May 08, 2010 at 02:54:35PM -0700, Linus Torvalds wrote: [...] >> You could talk about "binary" vs "text", and it would make sense, but your >> argument that "eol" is somehow better than "crlf" is just insane. >> >> So I could certainly see >> >> *.jpg binary >> *.txt text >> >> making sense. But "eol" is certainly no better than "crlf". > > What about .sln files? They are xml files with CRLF ending. Does it mean > they are binary? Based on how it is stored, it is certainly binary, but > when it comes to "diff" or even "merge" you may want to think about them > as text, and, in general, people tend to think about them as text files. > > Another example is shell scripts. You really want them to be LF even on > Windows. So, is it a binary file too? I think "binary" and "text" are the wrong things to talk about in this case. If we were to following Avery's suggestion that we look at what we would have implemented had autocrlf not already existed, it would be better to call "crlf" something like "eolconv". You're not saying that a file is text or binary as such, rather that "I want eol conversion for this file" or "I don't want eol conversion for this file". Flagging a file as "-eolconv" because it should always have LFs or always CRLFs seems logical to me. "eolconv=auto" also makes sense. [...] >> In the end, crlf is what we have. We're not getting rid of it, so if >> somebody were to actually rename it, that would just mean that there are >> _two_ different ways to say the same thing. And quite frankly, I think >> that's worse than what we have now, so I don't think it's worth it. > > I was not sure myself that the idea of renaming worth it... While I do > think that "eol" is a better name than "crlf", but not by big margin, > and as you said crlf is what we have now... so be it... Renaming "crlf" might not be worth it, but thinking about what it should look like definitely is worth it. Since I already have a patch series that changes this area, I'd like for it to be future proof. I think the idea that we're stuck with "crlf" (or any bad ui design) for ever and ever is depressing, and I reject it. It would be easy to create a new attribute with a better name that is the same setting under the hood, and deprecate "crlf". The old attribute would still work in existing repositories (indefinitely, if needs be), but new users wouldn't have to be confused by its poor name. I'm not saying I want to replace "crlf" right now! I'm just saying that it makes sense to think about how we would want to replace it, and try not to introduce any new change that will make it harder to do the right thing later. -- 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