git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Feb 24, 2009, 06:11 UTC
Message-ID
<20090224061134.GF4615@coredump.intra.peff.net>
In-Reply-To
<59288.77.61.241.211.1235374197.squirrel@hupie.xs4all.nl>
On Mon, Feb 23, 2009 at 08:29:57AM +0100, Ferry Huberts (Pelagic) wrote:
Show 7 quoted lines
> > 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.
Show 5 quoted lines
> 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
Previous: Ferry Huberts (Pelagic)Next: Ferry Huberts (Pelagic)
Message 22 of 26 in “CVS import”
  1. Ferry Huberts (Pelagic)Feb 16, 2009
  2. Ferry Huberts (Pelagic)Feb 16, 2009
  3. Johannes SchindelinFeb 16, 2009
  4. Johannes SchindelinFeb 16, 2009
  5. Ferry Huberts (Pelagic)Feb 16, 2009
  6. Johannes SchindelinFeb 16, 2009
  7. Ferry Huberts (Pelagic)Feb 16, 2009
  8. Johannes SchindelinFeb 16, 2009
  9. Ferry Huberts (Pelagic)Feb 17, 2009
  10. Johannes SchindelinFeb 17, 2009
  11. Ferry Huberts (Pelagic)Feb 17, 2009
  12. Jeff KingFeb 20, 2009
  13. Ferry Huberts (Pelagic)Feb 20, 2009
  14. autocrlf=input and safecrlf (was Re: CVS import [SOLVED])Jeff King, Feb 20, 2009
  15. Ferry Huberts (Pelagic)Feb 20, 2009
  16. Jeff KingFeb 23, 2009
  17. Ferry Huberts (Pelagic)Feb 23, 2009
  18. Jeff KingFeb 23, 2009
  19. Ferry Huberts (Pelagic)Feb 23, 2009
  20. Jeff KingFeb 23, 2009
  21. Ferry Huberts (Pelagic)Feb 23, 2009
  22. Jeff KingFeb 24, 2009
  23. Ferry Huberts (Pelagic)Feb 24, 2009
  24. Jeff KingFeb 25, 2009
  25. Ferry Huberts (Pelagic)Feb 25, 2009
  26. Jeff KingFeb 25, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.