On Mon, Nov 03, 2008 at 05:05:24PM +0200, Hannu Koivisto wrote: > > Actually, even if .gitattributes were applied in checkout, I think > the whole CRLF support is broken by design because people will have > to remember to use -n in clone, then enable core.autocrlf support > and then checkout. This makes it unneccessarily complicated to > create "quick local clones" as well. You might suggest that > Windows users should enable core.autocrlf globally but it may not > be the right thing to do for all projects/repositories either. core.autocrlf was exactly meant to be set globally. Basically, it says what end-of-line should be on your system. It is strange to have it different for different repositories. > > I think CRLF conversion support should have some attribute (be it > .gitattributes attribute or something else) that is somehow > inherited from the parent repository. It would basically say that > "you should use platform's native line end type for text files with > this repository and its children". It is already so. All text files are treated accordingly to users preferences, and for those files where automatic heuristic produces undesirable result, it can be disabled using .gitattributes. (Alas, there is a bug with checkout that you encountered earlier). > To go with that, one would > maybe have a configuration option to tell what that platform > default line end type is (just in case someone wants to pretend > Cygwin is Unix or something like that). That is exactly what core.autocrlf is about. One user may want to have LF on Windows and another wants CRLF. So, core.autocrlf defines how text files should be treated. It is what each user may have in his/her own ~/.gitconfig. > > I also observed this problem: > > # Pretend someone does this on Unix > mkdir test1 > cd test1 > git init > echo "*.c crlf" > .gitattributes > echo -en "foo\r\nfoo\r\nfoo\r\n" > kala.c The 'crlf' attribute means that the file should be treated as 'text' without applying heuristic. The correct ending for text files on Unix is '\n', not '\r\n'. So, you put a text file with incorrect ending, not surprisingly it causes problems for Windows users later. Dmitry -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
