Thread (54 messages) flat view 54 messages, 9 authors, 2016-06-15

Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:45:00

Hi,

On Wed, 23 Jul 2008, Eyvind Bernhardsen wrote:
On 23. juli. 2008, at 20.57, Johannes Schindelin wrote:
quoted
On Wed, 23 Jul 2008, Avery Pennarun wrote:
quoted
1. always CRLF on all platforms (eg. for .bat files)
2. always LF on all platforms (eg. for shell scripts and perl scripts)
3. just leave it alone no matter what (eg. for binary files)
These are not different, but equal.  "Do no harm to the contents of this
file".
That is only true until someone edits the file in an editor which 
prefers the wrong end-of-line marker, and converts to it when saving.  
It will be obvious that this has happened if the user does a "git diff" 
before committing, but I think the intent of nos. 1 and 2 is for git to 
automatically convert the line endings back instead of kicking up a 
fuss.

Might be too magical, though.
I deem it not, uhm, magical.  By your reasoning there should be a way for 
Git to convert a file to UTF-8 when some entertaining person converted the 
working directory file to ISO-8859-15.

Really, either it is CR/LF on all platforms (and then the project members 
have to live by it), or it is not.  You cannot have both.

If it is CR/LF on all platforms, you just _commit_ it as CR/LF.  No 
conversion, not even a brain required.

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help