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

From: Steffen Prohaska <prohaska@zib.de>
Date: Mar 23, 2008, 13:42 UTC
Message-ID: <alpine.OSX.1.00.0803231428220.13789@cougar>
In-Reply-To: <alpine.LSU.1.00.0803231404390.4353@racer.site>

On Sun, 23 Mar 2008, Johannes Schindelin wrote:

Show 22 quoted lines

> On Sun, 23 Mar 2008, Steffen Prohaska wrote:
> 
> > On Sun, 23 Mar 2008, Johannes Schindelin wrote:
> > 
> > > On Sun, 23 Mar 2008, Steffen Prohaska wrote:
> > > 
> > > > On Sun, 23 Mar 2008, Johannes Schindelin wrote:
> > > > 
> > > > Setting autocrlf for every repository limits the user's options to
> > > > override the default.
> > > 
> > > Then maybe a way for the user to override the global templates is what we 
> > > need?  I can see that this would be useful outside of the crlf issue.
> > 
> > I do not think we need this.  autocrlf is a configurable variable and we 
> > already have a mechanism for the user to override configuration 
> > variables.  The user can use "git config --global ..." to sets his 
> > preferences.  This mechanism is well established.  I do not see a reason 
> > not to use it.
> 
> The point is: if we use /etc/gitconfig, we also touch _existing_ setups 
> (as Junio pointed out).  Which, in the case of autocrlf, is not desirable.

I proposed a mechanism that would avoid such problems in the future. Repositories that would copy the current setting of autocrlf to their local .git/config would be shielded from future changes to the global setup.

> And if we go the route via templates, $HOME/.gitconfig will do no good, as 
> the configuration in the repository trumps the --global configuration.

We have two conflicting objectives and I do not know how to meet them the same time:

 1) Existing setups should not break.

 2) Users should have a way to set a global default for autocrlf that
    overrides our defaults.

If we store the new default in newly created repositories, (1) would be met but (2) is not possible. If we support ~/.gitconfig for overriding the system-wide default, (2) is trivial but (1) is hard to meet.

I propose to break existing setup and provide a simple mechanism to avoid such breakages in the future. As you pointed out earlier we are still only releasing "previews" on Windows and one reason for this decision was the lacking support for autocrlf. We always knew that some work would be needed before we have a sane setup on Windows.

Maybe we can improve the installer to warn the users that the default has changed and existing repositories must either be converted or the global default must be overridden. The installer could ask the user to confirm this change. Maybe this is sufficient to avoid further complains about weird behavior after upgrading.

            Steffen