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

[hasen j <hasan.aljudy@gmail.com>]

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