On Mon, Feb 16, 2009 at 09:59:29PM +0100, Johannes Schindelin wrote:
> > I'm working on it now, and did some more testing: it's actually the
> > safecrlf setting, not the autocrlf option.
>
> Oh. That probably means that cvsimport gets confused by the extra
> warnings.
>
> However, I think it is not correct to run cvsimport with autocrlf set to
> anything than false anyway (and safecrlf would not trigger then, right?).
>
> So IMHO the solution is still to force autocrlf off.
I don't think that's right. What is happening is that git-hash-object is
barfing, and git-cvsimport is not properly detecting the error.
something like this (untested) would make that better:
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index e439202..65e7990 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -926,6 +926,7 @@ while (<CVS>) {
my $sha = <$F>;
chomp $sha;
close $F;
+ $? and die "hash-object reported failure";
my $mode = pmode($cvs->{'mode'});
push(@new,[$mode, $sha, $fn]); # may be resurrected!
}
But the problem is not autocrlf. It is that the combination of "autocrlf
= input" and "safecrlf" is nonsensical. Just try this:
$ git init
$ git config core.autocrlf input
$ git config core.safecrlf true
$ printf 'DOS\r\n' >file
$ git add file
fatal: CRLF would be replaced by LF in file.
which makes sense. SafeCRLF is about making sure that the file will be
the same on checkin and checkout. But it won't, because we are only
doing CRLF conversion half the time.
So the best workaround is disabling safecrlf, which makes no sense with
his autocrlf setting. But I also think safecrlf could be smarter by
treating autocrlf=input as autocrlf=true. That is, we don't care if in
our _particular_ config it will come out the same; we care about whether
one could, if so inclined, get the CRLF's back to create a byte-for-byte
identical object.
-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
