On 10/1/08 20:50, "Rogan Dawes" <lists@xxxxxxxxxxxx> wrote: > Gregory Jefferis wrote: >> Isn't plain git functionally agnostic about line endings? You can >> check in CRLF text files to git and it doesn't care. You can diff, show etc >> just fine. I haven't yet found anything that breaks with CRLF files. In >> this sense plain git is already Windows ready. Maybe I'm missing something? > > One example that bit me recently was "git-apply --whitespace=strip" > > I have files with CRLF in my repo, but git was stripping the CR from > lines that I applied via a patch. > > I worked around it with a smudge/clean filter of "dos2unix | unix2dos" > (first removes all CR's, second puts one back on each line) > > Rogan OK so that's interesting. Is it a case where core git is not crlf agnostic? Looks like CR is being considered whitespace. I think git diff --ignore-space-at-eol also works because CR is considered whitespace. Maybe that's the wrong behaviour. So the big question for me. Should git expect that text files inside a repository have to have LF only line endings? I don't think that it should, but should accommodate both CRLF and LF. I guess at the moment git normally accommodates CRLF files because they look like an LF file that happens to have a funky whitespace char in front of the LFs. Maybe it would be better if edge cases like the one you described were ironed out. - 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
