Re: suggestion for improved docs on autocrlf

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 12, 2019, 15:46 UTC
Message-ID: <xmqqo90ubd3g.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <64c0a35825af4ff3956c6c9a5fb748bb@bofa.com>

"Yagnatinsky, Mark" <mark.yagnatinsky@bofa.com> writes:

Show 8 quoted lines

> Wait a second... suppose a file is committed with CRLF line
> endings.  You're saying that even if I have autocrlf set to
> "input" or "auto", the file will never get "converted" to LF
> format unless I explicitly renormalize?  That sounds like a fairly
> sensible behavior, but it's not what I've observed in the past at
> all!  There have been plenty of times when I had "autocrlf" set to
> input which resulted in me changing line endings on commit I had
> no intention of changing!

Isn't that merely an effect of the fact that git add does not bother with paths it knows unmodified, and the decision it makes if a path is modified does not involve if the path's contents predate what you have in the current .gitattributes and .git/config?

If you had committed two paths with CRLF, checked them out, flipped the attribute so that they would be converted upon input, modified one of them but not the other, and say "git add .", because the relative age of .gitattributes and file contents do not get in the picture, "git add ." would say "Ah, you have one modified file, so we need to add its new contents to the index. And you are telling me to convert its line endings to LF while doing so."