Re: CRLF, LF ... CR ?

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

Hi Jeff and Drew.

I've been messing a little with clean/smudge filters; I think I understand them partly.

Let's call the file I have on the server that have <cr> line endings, "mypcb.osm".
If I clone the project, and do the following...
$ cat mypcb.osm | tr '\r' '\n'
I can read the file in the terminal window, otherwise it's just a "one-line-file".

So far, so good.
In my home directory, I have a .gitconfig file, here's the interesting part:
[core]
        editor = nano
        excludesfile = /Users/jens/.gitexcludes
        attributesfile = /Users/jens/.gitattributes

[filter "cr"]
        clean = tr '\\r' '\\n'
        smudge = tr '\\n' '\\r'


In my home directory I added .gitattributes:
*.osm   filter=cr

I've verified that .gitattributes is read; because if I add two spaces, like "*.osm filter = cr", I get an 'invalid filter name' error.
I've also verified that the clean/smudge lines are read; if I only have '\n' for instance, I get an error.

Now, when I clone the project, make a change and then issue this command...
$ git diff mypcb.osm

...I get a strange diff. On line 3, one of the files shows a lot of control-m (<cr>) lines.
After that, I see <lf> lines, all prefixed with a '+', as if they were added.

I think I might be nearly there, just missing some obvious detail somewhere.
Any hints ?


Love
Jens

On Thu, 13 Sep 2012 17:53:00 +0200, Jens Bauer wrote:
> 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
> --
> 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