Re: What's cooking extra

[Clemens Buchacher <drizzd@aon.at>]

On Sun, May 23, 2010 at 02:53:18PM +0200, Eyvind Bernhardsen wrote:
> On 23. mai 2010, at 13.51, Clemens Buchacher wrote:
> 
> > 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.

That I can imagine. But due to their change, the file will not work
any more, not even on their own platform. What did they even make
the change for then?

> I don't have strong feelings about the need for this feature, but
> it has been requested so it's probably useful.

Just because a feature is requested doesn't mean it's useful, or
even harmless. This has nothing to do with version control in the
first place, so I do not see why we should suffer the additional
complication.

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

With CRLF file in the repository, core.autocrlf=true and
core.eol=lf, I tested the patches currently in pu (0ed6711a) in the
following three scenarios:

1. no attributes are set
2. text attribute is set or auto
3. eol attribute is set to lf

In the first scenario, the behavior is completely asymmetric. LF
files will be converted to CRLF, if core.eol=crlf, but CRLF files
will _not_ be converted to LF, even if core.eol=lf. And it will not
be marked as dirty either. Yet this is the default behavior in
terms of attributes.

The only justification I can think of for this behavior is the fact
that on platforms with LF line endings, most tools can deal with
CRLF line endings. Not very convincing.

In the second scenario, the file is marked as dirty. Neither reset
--hard nor checkout HEAD . fix the problem. The file has to be
added and committed, after which the line endings are _still_ CRLF.
This appears to be the old autocrlf=true behavior. Is this
intentional?

The third scenario is similar to the second scenario, only it warns
me about CRLF conversion during add and commit. The file still ends
up having CRLF line endings in the work tree. git reset --hard does
not fix the line endings. touch'ing the file finally makes git diff
notice that the file is dirty, but git status still does not list
the file.

So to me, end of line conversion is still as confusing as it gets.

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

In other words, this will be a problem all the time, since by
default people will not even know about text or eol.

Clemens