On Wed, February 25, 2009 07:56, Jeff King wrote: > 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 > 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 -- 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
