Subject: autocrlf

From: Andy Parkins <[email-masked]>
Date: Fri, 18 May 2007 11:11:52 +0100

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
[email-masked]