> > It's that simple. You seem to totally miss the whole point of the whole > feature in the first place. > > Linus Sure, I won't deny, it always baffled me why it's built into git. The only good reason I could think of is avoiding scenarios someone saves a file with different line endings and then all merging hell would break loose because all lines are changed. Although theoretically I think that can be avoided if the merge algorithm normalized line endings before the merge (but really, I don't know anything about merging). Under this assumption, the point of autocrlf is that windows users should commit with LF endings even if they use CRLF in the working directory (e.g. some stupid text editor resaves files with crlf). If that's not the reason, then why the hell does git care about converting line ending styles? If the only reason is "LF is not a new line in Windows", then I'll go back to my previous opinion that autocrlf is useless most of the time and shouldn't be builtin; use smudge/clean filters instead if you really need crlf files. >> ... [XML processors] MUST behave as if it normalized all line >> breaks in external parsed entities (including the document entity) on >> input, before parsing, by translating both the two-character sequence >> #xD #xA and any #xD that is not followed by #xA to a single #xA >> character. > > Erm, this seems to be a counterexample to your point. It says very > clearly that the files can use either LF or CRLF line endings, and > will be parsed correctly either way, or your parser is broken. So > pretty much any CRLF conversion rule (or none at all) will work with > such files. Agreed. This is an example where all line endings are valid on all platforms. > > Hasen wrote: >>> The way git handles crlf is just confusing; in fact it's so confusing >>> that it's often better to just turn it off. > > True. This discussion is about fixing that, though, so it seems > unnecessary to make that point. It is necessary. It's broken because the assumptions it's built on are wrong. >> Hasen makes a good point here. It is simply this, the LF issue does >> not boil down to a single boolean switch. People who think of the >> LF/CRLF issue as a boolean switch are not dealing with all the facts. >> There's a lot of grey, not simply black and white. > > How on earth is anyone suggesting that it's a simple boolean switch? > Linus posted an 8-cell truth table earlier, and he hadn't even > included all the cases. That's cool and all, but we need to simplify it; not make it more confusing. The name autocrlf is confusing all by itself: what does it mean? is it a two way conversion or a one way conversion? Where the hell did "input" come from? I always have to pull up the man pages. I'd rather be able to say: - My over all preference is 'lf' - For this repo, this file here is always 'lf' (takes precedence over the above preference) - And this other file here is always 'crlf' (ditto) This model makes way more sense for me as a user and for the project. >> Confusion, yes. The Git documentation is very confusing on this >> point... Linus and Junio may want to lift a page from the Perforce >> book ;) > > I've learned that git people never learn from anyone's book. svn has > also had this problem solved pretty much forever, and would be easy to > copy. For better or for worse, it all has to be hashed out from > scratch or it won't happen. No, I actually think git got source control right exactly because it didn't bother copying other existing systems. The other system's solutions don't necessarily fit with git's model. -- 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