Hi David.
Thank you for the information.
I am not the one to decide whether or not this should be a built-in feature;
I'm only a plain user. :)
My personal opinion: If it was a built-in feature, people all over the World
would not be getting into trouble with it.
I've seen on the net, that even on PC (I don't know if it's DOS or Windows), a
user wrote a program, that did not output CRLF, nor LF, but only CR.
Perhaps git does not treat LF or CRLF in any special way, if that's the case,
git's very beautifully programmed.
-But gitweb does not seem to make correct output unless I add a clean/smudge
filter.
In addition to that, there is also the detail, that the terminal treats CR and
LF differently...
echo -e "this\ris\ra\rtest"
will in bash only output...
test
...while
echo -e "this\nis\na\ntest"
in bash outputs...
this
is
a
test
...This means that 'git diff' will (to the user) only output a single line of
"junk", when line-endings are CR and not LF or CRLF.
Also... git diff says that a file containing CR line endings have no
end-of-line, which to me appears as that git diff thinks there is only one line.
Finally, when I want to display the file using head, cat or tail, I still see
only one line of text. [That's correct behaviour!]
As you mentioned, there are good possibilites for fixing these things using
clean/smudge filters.
The clean/smudge filter I ended up using is quite simple (much simpler than I
first thought it would be).
I ended up with...
[filter "cr"]
clean = tr '\\15' '\\12'
...and no smudge, because the application supports reading lines ending in LF,
so I wanted the files to stay readable.
-But normally, there should ofcourse be a smudge filter, that reverses \15 and
\12.
In my opinion, the benefit from having git diff support CR, would be that the
user does not lose the history if he/she wants to 'clean' the projects.
Existing projects would be shown correctly. Of course, gitweb would need to
support CR, so it generates correct line endings, instead of showing one long
line with a lot of "\r" in them.
[When thinking about all these CR/LF problems, I am grateful that Sinclair
Research did not continue to use the ZX81 characterset in the ZX Spectrum.
Imagine a mess we could have had!]
Love
Jens
On Thu, 13 Sep 2012 21:06:32 -0700, David Aguilar wrote:
> On Thu, Sep 13, 2012 at 8:09 AM, Jens Bauer <jens-li...@gpio.dk> wrote:
>> Hi everyone.
>>
>> I'm quite fond of git, and have used it for a while.
>> Recently, I've started making printed circuit boards (PCBs) using an
>> application called OsmondPCB (for Mac), and I'd like to use git to
>> track changes on these.
>> This application was originally written for the old Mac OS (Mac OS 6
>> to Mac OS 9.2).
>> The old Mac OS does not use LF, nor CRLF for line endings, but only CR.
>>
>> 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) ?
>> The alternative is to ask the developer if he would change the file
>> format, so that new versions of his software would change the files
>> to end in LF, but he'd have to be careful not to break compatibility.
>> If the software is to be changed, this would not fix similar issues
>> that other people might have.
>
> Do you mean that you want automatic conversion from CR to LF?
>
> What's about just storing the files as-is,
> with no conversion at all? (this is the default git behavior)
>
> git doesn't really even support LF. It stores content as-is which
> means LF works just fine. git prefers to not mess around with the content,
> but we do have autocrlf to help folks stuck on windows.
>
> If you need to, you can use .gitattributes to add a clean/smudge filter
> that does this conversion for you.
>
> See the "filter" section for an example:
>
> http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
>
> If you're serious about wanting that feature then we'll
> happily review any patches you might have. That said, I don't really
> think it's a common enough case for git to natively support, so
> I'd recommend going with the .gitattributes filter.
>
> good luck,
> --
> David
--
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
