Jeff King wrote:
On Fri, Feb 20, 2009 at 05:25:43PM +0100, Ferry Huberts (Pelagic) wrote:
I replied in the thread with something comparable:
http://article.gmane.org/gmane.comp.version-control.git/110358
My suggestion is make sure that safecrlf is set to false (see the end
part of the mail)
Oh, sorry, I missed that bit. You said:
Back to the issue:
I think requiring autocrlf = false is too strict. Requiring autocrlf
= false should be enough. That combined with a bit of text in the
manual page about these settings: autocrlf = false is strongly
recommended. Also, safecrlf is required to be set to false.
Assuming there is a typo and you meant to say "Requiring safecrlf =
false should be enough", then yes, I agree. But if you are recommending
yes that was a typo.
to put that into the "git cvsimport" manpage, I'm not sure that makes
sense. Setting autocrlf to input and turning on safecrlf breaks much
more than that; you can't add any file that has a CRLF in it. So such a
warning should probably go in the config description for those options.
I meant that I would add a patch that makes sure that a new repository
is created with that option set to 'off' and that an existing repository
would be checked for that option set to 'off'. I suggested to _also_ add
remarks about this in the man page of cvsimport. Johannes already
suggested a patch but that was for the autocrlf option (trivially
converted to the safecrlf option)
I still think safecrlf could probably be made more useful in this case
to differentiate between "this will corrupt your data if you do a
checkout with your current config settings" and "this will corrupt your
data forever". But I am not a user of either config variable, so maybe
there is some subtlety I'm missing.
-Peff
I'm a user of these options myself. I maintain several large
repositories that contain data that is used both on Unix and Windows
platforms and that have the autocrlf=input and safecrlf=true. This makes
sure that everything is in Unix format.
Your remark about corrupting your data is a bit strong for my taste.
Corruption from one point of view, making sure that everybody handles
the same content from another :-)
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
