On Mon, Feb 23, 2009 at 08:29:57AM +0100, Ferry Huberts (Pelagic) wrote: > > Wouldn't setting autocrlf=true, safecrlf=true do the import you want? > > Then you could reset autocrlf to input after import but before checkout > > time. > > No. As I demonstrated in my testing setup the combination of autocrlf=true > and safecrlf=true ALWAYS makes the import NOT work (for repositories that > have CRLF files). In my own experience I also found that the combination OK, sorry I missed that before. It actually works fine with CRLF files. It breaks on _LF_ files. Look again at the output you posted, which shows it barfing while working on unix.txt. This is the flip-side of the CRLF and autocrlf=input problem; safecrlf is protecting us from the case where the file would change on checkout, in addition to when it would actually be corrupted. But both of those checks (CRLF on autocrlf=input and safecrlf=true, and LF on autocrlf=output/true and safecrlf=true) aren't useful to us here; we are not coming from the working tree to git, and worried about getting back. We are munging input coming from cvs, and whatever gets put into the working tree is fine (as long as it is not binary corruption). So I think the right solution is a relaxed safecrlf mode that protects against corruption, but not these other cases. And then git-cvsimport should use that. In the meantime, detecting the situation is not a bad idea. > of autocrlf=input and safecrlf=true ALWAYS makes the import NOT work for > PRATICAL repositories. That lead me to the conclusion to require > safecrlf=false. From the discussion and arguments from you it appeared > that that wouldn't be enough. Therefore I think that we have to require > autocrlf=false (which makes git ignore the safecrlf setting). 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. -Peff -- 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
