autocrlf

Hello,

I've just been playing with gitattributes and was trying the crlf attribute.  
The behaviour of this and/or core.autocrlf is not as I was expecting.

What I had imagined was that I could use .gitattributes to tell git which 
files in my tree were text.  Then the line endings on checkout would be set 
as appropriate to my platform, and on check in set to LF.

What actually happens is that any file with the crlf attribute is being 
checked out with LF expanded to CRLF (I'm running Linux of course), which is 
completely not what I wanted.

I've looked at convert.c:crlf_to_worktree(), and it seems that that is exactly 
what is programmed:

    dst = buffer;
    do {
        unsigned char c = *src++;
        if (c == '\n' && last != '\r')
            *dst++ = '\r';
        *dst++ = c;
        last = c;
    } while (--size);

This seems completely crazy.  What is automatic about that?  I had imagined 
the point of the crlf flag was to make it possible for windows users and 
linux users to work on the same project, each using their native line endings 
locally.  Have I misunderstood?  Am I doing something wrong?

How would you set up a repository so that checking it out on Linux results in 
LF endings, and on Windows it results in CRLF endings?

This also makes me think that the crlf attribute is wrong; what I really want 
to say in .gitattributes is something like

# Check out text to platform-dependent endings
*.txt lineending=native
# Check out svg to LF endings
*.svg lineending=lf
# Check out Z80 assembly files to CRLF
*.mac lineending=crlf
# Check out png untouched
*.png lineending=binary

With the default for the lineending attribute being "binary".

Then in .git/config I would have "core.nativelineending = crlf"; with the 
default being to use the ending appropriate to the platform.

I'll write patches for this, but I wanted to make sure I haven't completely 
gotten the wrong end of the stick before I do.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

On Fri, 2007-05-18 at 11:11 +0100, Andy Parkins wrote:

Hello,

I've just been playing with gitattributes and was trying the crlf attribute.  
The behaviour of this and/or core.autocrlf is not as I was expecting.

What I had imagined was that I could use .gitattributes to tell git which 
files in my tree were text.  Then the line endings on checkout would be set 
as appropriate to my platform, and on check in set to LF.

What actually happens is that any file with the crlf attribute is being 
checked out with LF expanded to CRLF (I'm running Linux of course), which is 
completely not what I wanted.

you need to set core.autoCrlf=input

I had the same problem some time ago ...

Andy

-- 
best regards

  Ray

Andy Parkins wrote:

What I had imagined was that I could use .gitattributes to tell git which
files in my tree were text.  Then the line endings on checkout would be set
as appropriate to my platform, and on check in set to LF.

What actually happens is that any file with the crlf attribute is being
checked out with LF expanded to CRLF (I'm running Linux of course), which is
completely not what I wanted.

If I understand the documentation correctly
(Documentation/gitattributes.txt) then you set core.autocrlf to true on
Windows and false everywhere else, and things should start working like
you imagined.

I have not checked whether the behavior is according to the
documentation, though.

-- Hannes

On Friday 2007 May 18, Raimund Bauer wrote:

you need to set core.autoCrlf=input

I had the same problem some time ago ...

The documentation says:

core.autocrlf::
    If true, makes git convert `CRLF` at the end of lines in text files to
    `LF` when reading from the filesystem, and convert in reverse when
    writing to the filesystem.  The variable can be set to
    'input', in which case the conversion happens only while
    reading from the filesystem but files are written out with
    `LF` at the end of lines.  Currently, which paths to consider
    "text" (i.e. be subjected to the autocrlf mechanism) is
    decided purely based on the contents.

That is: "input" ensures that CRLF is stripped on input to the repository.  
While that is fine in some circumstances, the situation I'm describing here 
is what happens on output from the repository.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

On Friday 2007 May 18, Johannes Sixt wrote:

quoted

What actually happens is that any file with the crlf attribute is being
checked out with LF expanded to CRLF (I'm running Linux of course), which
is completely not what I wanted.

If I understand the documentation correctly
(Documentation/gitattributes.txt) then you set core.autocrlf to true on
Windows and false everywhere else, and things should start working like
you imagined.

Presumably then it is defaulting to false for Linux as everything is working 
fine for me at present.  However, that is not the case when I set the crlf 
attribute.

Documentation/gitattributes.txt:

This attribute controls the line-ending convention.

Set::

    Setting the `crlf` attribute on a path is meant to mark
    the path as a "text" file.  'core.autocrlf' conversion
    takes place without guessing the content type by
    inspection.

I read that as meaning the automatic detection of file type is overridden by 
the crlf attribute.  What I'm actually seeing is that it has the same effect 
as enabling "autocrlf = true" for that file.  As you say "autocrlf = true" is 
for windows, the crlf attribute should not be forcing it on as that then 
applies to all platforms.

I think this is a bug.  The code agrees with the observed behaviour but not 
with the documentation.  Patch to follow.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com