Re: What's cooking extra

From: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Date: May 23, 2010, 12:53 UTC
Message-ID: <744D05D2-FC47-45E5-92A1-CD93B0901E0C@gmail.com>
In-Reply-To: <20100523115127.GA20443@localhost>

On 23. mai 2010, at 13.51, Clemens Buchacher wrote:

Show 11 quoted lines

> On Sun, May 23, 2010 at 12:36:51PM +0200, Eyvind Bernhardsen wrote:
>> Yeah, that's what I initially thought too, but it makes sense to
>> be able to use normalization to prevent line ending breakages in
>> your repository.  If a file needs CRLFs for some tool to work,
>> you don't want anyone to inadvertently convert it to LF, and
>> "eol=crlf" makes git enforce that.
> 
> Unsetting crlf/text already disables converting it to LF. The user
> would have to change the line endings in his work tree and commit
> the file with wrong line endings. I do not see how this can happen
> inadvertently.

That's because you don't use (or work with people who use) editors that mangle line endings without asking.  Modern versions of vi and Emacs don't do this, but the problem still exists in popular Windows editors.  I don't have strong feelings about the need for this feature, but it has been requested so it's probably useful.

[...]

Show 6 quoted lines

> No, I am aware of autocrlf=input, but apparently I did not
> understand the meaning of eol=lf correctly. So if a file has CRLF
> endings in the repository, and eol=lf, it will _not_ be converted
> to LF in the work tree? Conversely, if it has LF endings in the
> repository, and eol=crlf, it _will_ be converted to CRLF in the
> work tree?

That is correct, but "eol=lf" means that the file _should_ be LF-only in the repository.  If it isn't, the repository is "corrupted".  Such a file is marked as dirty when it is checked out and will be normalized to LF-only line endings when it is committed, at which point the repository will be fixed.

This should only be a problem if you set the "text" or "eol" attributes in an existing repository, or if someone adds CRLFs to a normalized file using an older version of git.

I'm sorry if I was unclear about Finn Arne's patch: "safe autocrlf" only applies when files are normalized due to core.autocrlf.  If "text" or "eol" is set on a file, the file is normalized to LF-only regardless of whether it contains CRs in the repository.

> I was expecting eol=lf and eol=crlf to be symmetric, which is also
> the reason for my reply to Finn's safe crlf patch.

I think they are symmetric in practice.  While it's possible to get the repository into a state where you will get CRLFs in a text file that should be LF-only, it is both unlikely and easily fixed.

-- 
Eyvind