Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo

Hello Hannes,

let me correct my previous statement:

On Mon, Apr 27, 2015 at 08:58:05PM +0200, Johannes Sixt wrote:

When I commit my C source code files with CRLF into the repository  
(because I do not set any line ending options or configurations or any  
'text' attributes or similar), do I then commit binary files or text  
files? Should I expect not to see any diffs?

Of course, you can see diffs.  The files are not binary in that
sense.

Johannes Sixt [off-list ref] writes:

I set none of these. But I do commit CRLF and expect to get CRLF
back. [...]

That works.  You will not encounter any problem.  (Supposing you
do not change the line ending options, of course.)

Finally, let me explain my previous statement:

Am 27.04.2015 um 08:11 schrieb Stepan Kasal:

quoted

Git does not support CRLF as the internal line separator.

I'm often asked: "How do I set up git so that it uses CRLF in text
files in the repository and checks them out with CRLF on Windows and
with LF on unixy systems?"

My answer to that question always was that you cannot configure the
internal line separator in git repo, it is always LF.  Your only
chance to support both line endings is to have LF in the repo and
configure the Windows client to do the conversion.

quoted

If you commit file in binary mode with CRLF, you are on your own.

OK, scratch the word "binary".  The files in the repo are actually
text files.  But each text line is contains one more char than you
would think.  From time to time, this lurks:

1) Does "git grep ';$' HEAD" find anything?
2) What about "git grep ';.$' HEAD" ?
   Or "git grep `printf ';\r$' HEAD"  ?

3) If you try things like
       git diff HEAD^^..HEAD^ >outfile.diff
   and then open outfile.diff with a suitable editor (e.g. vim), you
   can see an extra ^M at the end of some lines (the content ones).

This is why I tell users that they are on their own if they decide to
use the setup you described.

Have a nice day,
	Stepan