Re: What's cooking extra

From: Clemens Buchacher <drizzd@aon.at>
Date: May 23, 2010, 11:51 UTC
Message-ID: <20100523115127.GA20443@localhost>
In-Reply-To: <CDD31343-2352-434B-B875-2013DAF49CE7@gmail.com>

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

Show 14 quoted lines

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

Show 9 quoted lines

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