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

Re: mingw, windows, crlf/lf, and git

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:54

Johannes Schindelin [off-list ref] writes:
Hi,

On Mon, 12 Feb 2007, Junio C Hamano wrote:
quoted
I agree that we can assume editors can grok files with LF end-of-line 
just fine and we would not need to do the reverse conversion on checkout 
paths (e.g. "read-tree -u", "checkout-index").
In that case, a simple pre-commit hook would suffice.

No, the problem mentioned by Mark was a very real one: you _cannot_ rely 
on Windows' editors not to fsck up with line endings. The worst case is if 
the file contains _some_ CRLF and _some _LF_. Almost always I had the 
problem that it now converted _all_ LFs to CRLFs. Even those which already 
were converted.

So, if we are to support text mode, it is not one-way. If we do one-way, 
we really do _not_ support text mode, but pre-commit conversion to LF 
style text. And in this case, core git does not need _any_ change.
Well I disagree in two counts.

 - I do not see how you propose to solve some CRLF and some LF
   case with both-ways conversion.

 - Pre-commit hook would not be sufficient.  In a edit, diff,
   test and then commit cycle, diff and test step needs to look
   at whatever the editor left on the filesystem, so the changes
   to populate-filespec is needed to make diff part work.


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