Re: [RFC PATCH (GIT-GUI/CORE BUG)] git-gui: Avoid an infinite rescan loop in handle_empty_diff.

[Junio C Hamano <gitster@pobox.com>]

Alexander Gavrilov <angavrilov@gmail.com> writes:

>     $ git config core.autocrlf true

This operation, when done in an already populated work tree, invalidates
all the state that is cached in the index, and you would need to adjust
things to the altered reality caused by this operation before doing
anything else.  There are different reasons you would want to flip the
configuration after you have files in your work tree, and depending on the
situation, the correct adjustment would differ.

You may have started a project in this repository, your work tree files
all have CRLF endings that is your platform convention, and after adding
the files to the index (but before making a commit) you may have realized
that you would want to keep your project cross platform, and that may be
the reason you are flipping the configuration.  If that is the case, your
index is already contaminated with CRLF, but your files have the line
ending that is correct (for you).  You would want to remove the index and
"add ." to stage everything again before proceeding, to have the autocrlf
mechanism to correct the line endings in the repository objects.

This would be the best case in one extreme.

On the other hand, you may have cloned a cross platform project from
elsewhere (in other words, your objects and the index have the correct
line ending), the checkout was done without autocrlf and it does not match
the local filesystem convention to use CRLF, and that may be the reason
you are flipping the configuration.  If that is the case, before making
any changes to the work tree files, the right adjustment would be to
remove the index, and "reset --hard" to force a checkout that follows your
autocrlf settings, so that the work tree files are corrected.

This would be the best case in the other end of the extreme.

And there will be different cases in between these extremes.

I think clueful users who flips the configuration from the command line
would know all of the above, know what they want and can tell what the
best course of action would be, but I at the same time wonder if git-gui
should (and if so, can) offer a simple and safe way to help this process
from others.