Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization

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.

quoted

  ... [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:

quoted

quoted

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.

quoted

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.

quoted

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.