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