Re: CVS import [SOLVED]

From

Jeff King <peff@peff.net>

Date

Feb 20, 2009, 15:28 UTC

Message-ID

<20090220152849.GA3826@coredump.intra.peff.net>

In-Reply-To

<alpine.DEB.1.00.0902162157080.6289@intel-tinevez-2-302>

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.

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