使用 git-svn 和来自两个 VCS 的提交的行结尾不一致
我有一个远程 SVN 存储库和一个本地 git 存储库。使用 git-svn 我已将 git 链接到 SVN，并成功使用 git svn rebase 、 git svn dcommit 拉取并推送到远程 SVN 存储库。
但是，当其他人使用 SVN 查看我之前用 git 编辑的文件并尝试在 VS2010 中打开它们时，他们会收到一个对话框，告诉他们行结尾不一致。
我已经阅读了一些关于 git config 中的 core.safecrlf 选项的内容，但这能解决我的问题吗？我还有很多其他人签入，但我们都运行 Windows - 我认为行结尾会是相同的？
设置 core.safecrlf 会在签出和提交时保留相同类型的行结束吗？
I have a remote SVN repository and a local git repository. Using git-svn I have linked git to SVN and am successfully using git svn rebase, git svn dcommit to pull and push to the remote SVN repository.
However, when other people check out my previously-git-edited files with SVN and try to open them in VS2010, they receive a dialog telling them the line endings are inconsistent.
I've read a few things about the core.safecrlf option in git config, but would that fix my issue? I have a number of other people checking in, but we're all running windows - I figured the line endings would be the same?
Would setting core.safecrlf preserve the same type of line ends on checkout and on commit?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我最近一直在处理同样的问题。默认情况下，Windows 上的 Git 设置 core.autocrlf = true。发生的情况是，您的文件从 SVN 存储库中以 CRLF 行结尾检出，但以 Unix 样式 (LF) 行结尾提交。当您dcommit这些更改时，我相信这些文件也会以 unix 样式的行结尾推送到 SVN 服务器。现在，当有人使用 SVN 检查这些文件时，不会执行行结束转换。
您可以设置 core.autocrlf = false 以便不进行任何转换。如果您都在 Windows 中工作，那么应该不会有任何问题。如果您与 *nix 用户共享 SVN 存储库，那么您可能会开始出现不一致的情况。这就是 autocrlf 选项的原因。存储库应该保持一致，并且由于 Linux 不喜欢与 CRLF 很好地配合，因此应该将 autocrlf 设置为 true。
I have been dealing with this same issue lately. By default, Git on Windows sets core.autocrlf = true. What happens is that your files are checked out from the SVN repo with CRLF line endings, but are committed with unix-style (LF) line endings. When you dcommit those changes, I believe the files are pushed to the SVN server with the unix-style line endings as well. Now when someone checks out those files using SVN, no line ending conversion is performed.
You can set core.autocrlf = false so that no conversion is done. If you are all working in Windows, you shouldn't have any problems. If you are sharing the SVN repo with *nix users, then it is likely that you'll start having inconsistencies. This is the reason for the autocrlf option. The repos should remain consistent, and since Linux doesn't like to play nicely with CRLF, this autocrlf should be set to true.
行尾问题是 git-svn 众所周知的令人头疼的问题。我建议使用 SmartGit 来处理您的存储库。我尊重 svn:eol-style 值以在 Git 中使用正确的 EOL（将其转换为相应的 .gitattirbutes 值）。您还可以通过适当更改 .gitattirbutes 来控制推送到 SVN 时的 svn:eol-style 值。
如果您有权访问服务器，则可以使用另一种方法：只需将 SubGit 安装到您的 SVN 服务器中。然后，将在服务器上创建一个链接的 Git 存储库，以便每次推送到它时都会自动转换为 SVN，反之亦然。它还将 svn:eol-style 转换为 .gitattirbutes。
因此，我会推荐其中一种解决方案，但不推荐 git-svn，因为它（据我所知）在 Windows 上速度慢得令人痛苦。
Line endings problem is a well-known headache of git-svn. I would recommend to use SmartGit to work with your repository. I respects svn:eol-style value to use correct EOL in Git (translating to it to a corresponding .gitattirbutes value). You may also control svn:eol-style value on pushing to SVN by appropriate changes .gitattirbutes.
If you have an access to the server another approach is possible: just install SubGit into your SVN server. Then a linked Git repository will be created on the server such that every push to it will be automatically translated to SVN and vice versa. It also translates svn:eol-style to .gitattirbutes.
So I would recommend one of these solutions, but not git-svn that is (as I know) painfully slow on Windows.
以下是 GitHub 文章，介绍了在 Git 中处理行尾字符的选择：
https ://help.github.com/articles/dealing-with-line-endings
本质上，Git 有助于在不同操作系统上转换 EOL。 SVN也有类似的功能。您需要确保它们以一致的方式设置。
Here is a GitHub article that describes your choices for handling end of line characters in Git:
https://help.github.com/articles/dealing-with-line-endings
Essentially Git helps convert EOL on different OS's. SVN has similar functionality. You will need to ensure that they are set in a consistent manner.