From: Andy Parkins <andyparkins@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Subject: autocrlf
Date: Fri, 18 May 2007 11:11:52 +0100 [thread overview]
Message-ID: <200705181111.53823.andyparkins@gmail.com> (raw)
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
next reply other threads:[~2007-05-18 10:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-18 10:11 Andy Parkins [this message]
2007-05-18 10:34 ` autocrlf Raimund Bauer
2007-05-18 12:01 ` autocrlf Andy Parkins
2007-05-18 11:45 ` autocrlf Johannes Sixt
2007-05-18 12:32 ` autocrlf Andy Parkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200705181111.53823.andyparkins@gmail.com \
--to=andyparkins@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.