Alexander Gavrilov <angavrilov@xxxxxxxxx> 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. -- 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
