.git/info/exclude w/ CFLF fails in cygwin

.git/info/exclude w/ CFLF fails in cygwin

[Jing Xue]

(1.5.3.1 in cygwin, Win XP)
I have cygwin configured to operate in the DOS/text mode, which means
cygwin translates LF to CRLF when writing a file, and CRLF to LF when
reading.  Unfortunately cygwin's fstat() implementation doesn't take the
mode into account when reporting stat.st_size, presumably for the sake
of performance, while read() does actually do the conversion.

That causes the function add_excludes_from_file_1() in dir.c to reject a
.git/info/exclude file with CRLF ending, because the size actually read
is not the same as the size reported by fstat().

The simplest fix I have found is to explicitly open the exclude file in
binary mode, because the rest of the exclude file parsing code actually
deals with CRLF quite fine.

I would submit a patch but I am not sure if this is the appropriate fix.

By the way, parsing .git/config with CRLF in the same environment works
fine because the code reads the file by byte and doesn't do any size
validation.

Any thoughts?
-- 
Jing Xue

Re: .git/info/exclude w/ CFLF fails in cygwin

[Robin Rosenberg]

lördag 08 september 2007 skrev Jing Xue:
> (1.5.3.1 in cygwin, Win XP)
> I have cygwin configured to operate in the DOS/text mode, which means
> cygwin translates LF to CRLF when writing a file, and CRLF to LF when
> reading.  Unfortunately cygwin's fstat() implementation doesn't take the
> mode into account when reporting stat.st_size, presumably for the sake
> of performance, while read() does actually do the conversion.

This is not just cygwin and applies to all CRLF environments.

> That causes the function add_excludes_from_file_1() in dir.c to reject a
> .git/info/exclude file with CRLF ending, because the size actually read
> is not the same as the size reported by fstat().

> The simplest fix I have found is to explicitly open the exclude file in
> binary mode, because the rest of the exclude file parsing code actually
> deals with CRLF quite fine.
> 
> I would submit a patch but I am not sure if this is the appropriate fix.
doubt it is worth it..
> 
> By the way, parsing .git/config with CRLF in the same environment works
> fine because the code reads the file by byte and doesn't do any size
> validation.
> 
> Any thoughts?

I have cygwin in CRLF mode too, but I have binary-mounted the paths' where
I use git to avoid the problem. I did a half-hearted attempt to fix git in CRLF mode,
but it failed because in some places plumbing commands communicate via files
and in other pipes are used making it hard to get then right translation mode.

That is not to say it is impossible, but as I understand it the Cygwin project have
essentially given up on CRLF mode, so it will probably go away as programs get
updated and no longer works in translated mode.

Try git in unix mode and, if you need it, use the core.autocrl setting to have git
translate explicitly. There are plenty editors that honour line endings in Windows
so LF mode works out quite well nowadays (for me, on my machines).

-- robin