On 10/1/08 20:50, "Rogan Dawes" <lists@dawes.za.net> wrote:

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html