Re: Store autocrlf during init-db (was [msysGit] autocrlf problems with Git-preview20080301.exe)

On Sun, 23 Mar 2008, Johannes Schindelin wrote:

My patch does not set the default in git-init, but only stores the current choice of autocrlf in the repository's config. autocrlf is special because it cannot be easily changed after the initial checkout. Changing autocrlf might require converting the line endings of all files in the work tree. This is very different from most other configuration variables, which can be changed without requiring any modifications to the work tree.

In some sense you cannot change autocrlf at all after a repository is initialized. At least you need a deep understanding of the autocrlf mechanism to avoid unexpected behavior. Once you checked out files, these files might 'preserve' the setting of autocrlf during the checkout. For example if you use autocrlf=true during checkout and later change to autocrlf=false, git will detect all files as changed because they contain CRLF in the workspace but LF in the repository.

The situation is even worse, because the choice of autocrlf is not a purely local one, but depends on the project you are cloning. A sane policy is to have only LF line-endings in the repository and use native line-endings in the work tree. This can be guaranteed with autocrlf=input on Unix and autocrlf=true on Windows. Another possible choice is to tell git to not modify any content at all, which autocrlf=false would give you. Personally, I do not think the latter is a reasonable choice, but other might have a different opinion. My point is that it is the choice of the project: Either *all* repositories that clone the project should set autocrlf=input|true or *all* repositories should set autocrlf=false. It is neither the choice of the local admin, nor the local user, nor the default of git. You need to have project-specific knowledge to make the right choice.

I suspect that a lot of projects implicitly chose autocrlf=false because of lacking autocrlf support in the past. The default of git was to not touch the content at all; and still this is the default on Unix. Only lately we tried to provide a more sensible default on Windows.

All projects that implicitly assume autocrlf=false might get into trouble if we change the default, no matter which way we do this. For example we could use the templates to provide a new default. The existing repository's settings would not change. But the next time the user clones such a repository the clone would have the new settings and this would cause trouble if the project contains files with mixed line-endings. The same happens if we directly modify git's default. The only difference is that the trouble surfaces immediately because the new default affects existing repositories.

A possible solution would be if a project (not a single repository) could specify autocrlf and the choice was preserved across cloning. I do not advocate this solution. Such a mechanism is not available and I personally do not know why it should be added. As I pointed out above I believe that autocrlf=input|true is the only sane way of handling cross-platform projects and if git's binary auto-detection fails to detect a file you should by all means add it to .gitattributes. This is the only way to guarantee that the file will be properly handled with any autocrlf settings.

The solution I propose is to change the default now; tell the users about the change; explain again and again why it is good to enforce LF line-endings in the repository; and fix all repositories that contain CRLF line-endings ASAP.

But even if all repositories contained only LF, the original problem would remain. The work tree depends on the choice of autocrlf during checkout and cannot be easily modified later. Not only the admin or the maintainer of git can cause trouble by changing the default. The user himself can cause trouble by modifying the setup with "git config --global".

This is where my proposed patch kicks in. I propose to modify init-db to store the choice of autocrlf in the repository to preserve it for this repository, no matter who made this choice and no matter who decides to change the setup later. Only if the user deliberately chooses to modify the local setting of the repository he might get into trouble; but git always gives you this kind of freedom, no?

Yet the patch does not protect you from all trouble. It only works well in all cases if you have a repository that contains only LF. If this is the case you are free to choose autocrlf=input or autocrlf=true. Both will give you work trees without unexpected diffs right after checkout; and both choices will guarantee that CRLFs will never enter the repository. Still you must not thoughtlessly change autocrlf without fixing the line endings of the checked out files.

            Steffen