Re: autocrlf=input and safecrlf (was Re: CVS import [SOLVED])

From: Ferry Huberts (Pelagic) <ferry.huberts@pelagic.nl>
Date: Feb 25, 2009, 08:03 UTC
Message-ID: <45197.77.61.241.211.1235548980.squirrel@hupie.xs4all.nl>
In-Reply-To: <20090225065624.GA1678@sigill.intra.peff.net>

On Wed, February 25, 2009 07:56, Jeff King wrote:

Show 16 quoted lines

> On Tue, Feb 24, 2009 at 10:25:12AM +0100, Ferry Huberts (Pelagic) wrote:
>
>> > So yes, in some sense it is safecrlf that is broken. I'm just concerned
>> > about tweaking the user's options behind their back. The import can
>> > happen differently than they expected no matter which of safecrlf or
>> > autocrlf you tweak. So I think you are better off to complain and die.
>>
>> The plan was:
>> - when creating a new git repo for cvs import: setup safecrlf=false
>> - when importing into an existing repo: check whether the safecrlf
>>   setting is set to false and crash and burn when not :-)
>>   (complain before going up in flames)
>
> Why is it OK to silently change the settings in the first case, but not
> the second? Don't both have the potential to screw up the user's import?
>

the option would be setup for the import repository only, not global nor system

Show 7 quoted lines

> Also, are settings going to be unset after the first import? If so, then
> further incremental imports will fail as described in your second case.
> But if not, then safecrlf is turned off for that repo, even for
> non-cvsimport commands, overriding anything in the user's ~/.gitconfig.
> For somebody doing a one-shot import, they are paying that price without
> any benefit.
>

this actually makes sense to me. I was only thinking about the continuous import use-case. In that light it would be better to just complain and die in the script. I guess I'll just implement that in the patch then.

Ferry