Re: What's cooking extra

[Clemens Buchacher <drizzd@aon.at>]

On Sun, May 23, 2010 at 12:36:51PM +0200, Eyvind Bernhardsen wrote:

> On 23. mai 2010, at 00.27, Clemens Buchacher wrote:
> 
> >> The "eol" attribute is used for files that need a specific line
> >> ending.  Setting it also sets "text".
> > 
> > If a file needs specific line endings, why enable conversion for
> > this file at all? Just make sure the repository contains the
> > correct version and unset the crlf attribute.
> 
> 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.

> > I do see the value of a global core.eol option, however, since it
> > allows me to convert to LF instead of CRLF, which AFAIK is not
> > currently possible.
> 
> Actually, since git normalizes to LF, "eol=lf" simply means
> "convert on input but not on output", which is what
> "core.autocrlf=input" currently does.  The fact that you didn't
> know this reflects the poor usability of core.autocrlf, which is
> one of the things this series is trying to rectify :)

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?

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.