On Wed, Jul 23, 2008 at 12:23:27AM +0100, Johannes Schindelin wrote: > Hi, > > On Wed, 23 Jul 2008, Dmitry Potapov wrote: > > > On Tue, Jul 22, 2008 at 10:56:04PM +0100, Johannes Schindelin wrote: > > > > > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
