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: Dmitry Potapov <hidden>
Date: 2016-06-15 22:44:59

On Wed, Jul 23, 2008 at 12:23:27AM +0100, Johannes Schindelin wrote:
Hi,

On Wed, 23 Jul 2008, Dmitry Potapov wrote:
quoted
On Tue, Jul 22, 2008 at 10:56:04PM +0100, Johannes Schindelin wrote:
quoted
When a file's crlf attribute is explicitely set, it does not make 
sense to ignore it, just because the config variable core.autocrlf has 
not been set.
Hmm... About a week ago, I was about to propose the same change, but 
after reading documentation and some thinking I was not able to convince 
myself that this change would be the right thing to do.
Well, I have a shared repository, where I set the attribute.  Now, every 
once in a while, people check in text _with_ CR/LF.  Yes, that is right, I 
marked it explicitely as crlf, yet I am on the whim of the people choosing 
to set the config variable or not.

And I could not care less what the documentation says: if it does not make 
sense, it does not make sense.
If you think that the current documentation does not make sense, why
don't you write something that will make sense? Really, the current
behavior may not be the best one, but at least it is consistent with
documentation, while your change may confuse users, because they may
expect one behavior, but git will act differently.

If I understand your change correctly, you take into account the crlf
attribute unconditionally only in worktree-to-git conversion, while you
still ignore it if core.autocrlf=false on checkout. Is it correct?  If
so, I think your patch does make sense, and it should not break anything
too badly, because you still respect core.autocrlf on checkout, but you
should have said that in your commit message.

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