Re: CRLF, LF ... CR ?

[Jens Bauer <jens-lists@gpio.dk>]

Hi Jeff and Drew.

Thank you for your quick replies! :)

The diffs look nasty yes; that's my main issue.
It can be worked around in many ways; eg a simple (but time consuming) way:
$ git diff mypcb.osm >mypcb.diff && nano mypcb.diff

-It'd be better to just pipe it into a regex, which changes CR to LF on the fly.

OsmondPCB is able to read files that has mixed LF and CR. (By mixed, I do not talk about CRLF)

The files do not need line-by-line diffing, but I think it would make it more readable.
Thank you very much for the hint on the clean/smudge filters. I'll have a look at it. =)


Love
Jens

On Thu, 13 Sep 2012 11:43:10 -0400, Jeff King wrote:
> On Thu, Sep 13, 2012 at 11:34:50AM -0400, Drew Northup wrote:
> 
>>> I've read that git supports two different line endings; either CRLF 
>>> or LF, but it does not support CR.
>>> Would it make sense to add support for CR (if so, I hereby request 
>>> it as a new feature) ?
>> 
>> Even if Git can't do CRLF/LF translation on a file it will still store
>> and track the content of it it just fine. In fact you probably want
>> translation completely disabled in this case. 
> 
> Yeah. If the files always should just have CR, then just don't ask git
> to do any translation (by not setting the "text" attribute, or even
> setting "-text" if you have something like autocrlf turned on globally),
> and it will preserve the bytes exactly. I suspect diffs will look nasty
> because we won't interpret CR as a line-ending, though.
> 
> Do the files actually need line-by-line diffing and merging? If not,
> then you are fine.
> 
> If so, then it would probably be nice to store them with a canonical LF
> in the repository, but convert to CR on checkout. Git can't do that
> internally, but you could define clean/smudge filters to do so (see the
> section in "git help attributes" on "Checking-out and checking-in";
> specifically the "filter" subsection).
> 
> -Peff