On Sun, 23 Mar 2008, Johannes Schindelin wrote:
> 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:
> > > >
> > > > > 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.
> > >
> > > Yes, but your solution feels a bit limited and "hot-needled" for just
> > > one purpose.
> >
> > What limits do you mean (except that it does still break existing
> > msysgit setups; but would avoid this problem in the future)?
>
> I have the impression that a problem just like this will arise again, just
> not with corelf, but with another setting that the admin might want to
> set per default in git-init, but the user might want to override.
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
--
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
