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
Thank you very much for the hint on the clean/smudge filters. I'll have a look
at it. =)
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).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html