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

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

you need to set core.autoCrlf=input

I had the same problem some time ago ...

On Friday 2007 May 18, Raimund Bauer wrote:

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

Andy Parkins wrote:

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, Johannes Sixt wrote:

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