我有一个远程SVN存储库和一个本地git存储库。使用git-svn我已经将git链接到SVN，并成功使用git svn rebase,git svn dcommit来拉和推送到远程SVN存储库。使用git-svn与来自VCS的提交不一致的行结束符
但是，当其他人用SVN查看我以前的git编辑文件并尝试在VS2010中打开它们时，它们会收到一个对话框，告诉它们行结束是不一致的。
我读过一些关于core.safecrlf选项的东西在git config中，但是会解决我的问题吗？我有一些其他人在检查，但我们都在运行窗口 - 我认为行结束会是一样的？
设置core.safecrlf是否在结帐和提交时保留相同类型的行结束符？
最近我一直在处理这个问题。默认情况下，Windows上的Git设置为core.autocrlf = true。会发生什么是您的文件从SVN回购利用CRLF行结尾检出，但是用unix样式（LF）行结尾提交。当你dcommit这些变化，我相信这些文件被推送到SVN服务器与unix样式的行尾。现在，当某人使用SVN检出这些文件时，不会执行行结束转换。
您可以设置core.autocrlf = false以便不进行转换。如果你都在Windows上工作，你不应该有任何问题。如果您使用* nix用户共享SVN回购，那么您可能会开始出现不一致。这是autocrlf选项的原因。回购应该保持一致，并且由于Linux不喜欢和CRLF一起玩，所以这个autocrlf应该设置为true。
只需注意，一旦设置被更改，您应该验证所有行结束是否如您所期望的那样。要做到这一点，你应该改变core.autocrlf属性，然后拉动Git回购。现在检查文件的行尾。最后，将所有更改提交为单个提交。从这一点开始，您只需验证您是否更改了设置的任何新环境（新机器，重新安装等）的此值。 – 2018-02-05 14:27:54
行结局问题是一个众所周知的git-svn头痛。我会建议使用SmartGit来处理您的存储库。我尊重svn：eol-style的值，以便在Git中使用正确的EOL（将其转换为相应的.gitattirbutes值）。你也可以通过适当的修改.gitattirbutes来控制svn：eol-style的值。
如果您有权访问服务器，可以使用其他方法：只需将SubGit安装到您的SVN服务器。然后，将在服务器上创建链接的Git存储库，以便每次推送到它都将自动转换为SVN，反之亦然。它还将svn：eol-style转换为.gitattirbutes。
所以我会推荐这些解决方案之一，但不是（我知道）在Windows上痛苦地慢的git-svn。
这里是一个GitHub的文章中描述了处理行尾字符在Git中你的选择：
https://help.github.com/articles/dealing-with-line-endings
本质上的Git有助于转换EOL在不同的操作系统。 SVN具有类似的功能。您需要确保它们以一致的方式进行设置。
停止破坏我的行结局可能！ – 2011-04-05 08:56:52