从 SVN 迁移到 git 后如何修复行结束问题？
我刚刚使用完成将 Subversion 存储库转换为 git。
git svn clone--stdlayout --authors-file=ourcommitters.txt svn://svn.internalserver.com
在执行此操作时，我将 git 标志“core.autocrlf”设置为“true”——以防万一。
良久之后，命令结束。我清理了生成的 git 存储库（删除不需要的分支、创建标签等），现在一切看起来都非常好并且运行良好。该存储库托管在 Linux 机器上，将其克隆到其他 Linux 机器上效果非常好。
但是，我注意到一个问题：将存储库克隆到 Windows 系统时，切换分支时某些文件似乎被修改。例如，我这样做：
git clone svn://our.git.server/foo
git status # Everything is clean
git checkout -t origin/maintenance # Switch to maintenance branch
git status # Everything is clean
git checkout master # Back to master branch
git status # A few files are modified!
在执行“git diff”时，我注意到修改后的文件似乎除了行结尾之外没有任何不同。当对此进行一些研究时，我们注意到这些文件在 Subversion 中意外地使用 CR-LF 行结尾（而不是 LF 行结尾）签入，并且此错误已转换到我们的 git 存储库中。
有没有什么方法可以在我们的存储库中解决这个问题（到目前为止它还没有经常被克隆，所以重写一些历史记录就可以了）而不需要进行“清理提交”或类似的操作？也许我们可以以某种方式默默地重写受影响的对象？
或者，我们可以在 Subversion 中修复此问题 - 然后再次发出上面的“git svn clone”命令。这似乎是增量工作的（它只会选取最后一行结束修复提交），但同样 - 它会创建一个提交。我想知道我是否可以解决这个问题。
I just finished converting a Subversion repository to git using
git svn clone--stdlayout --authors-file=ourcommitters.txt svn://svn.internalserver.com
While doing so, I had the git flag 'core.autocrlf' set to 'true' - just in case that matters.
After a long time, the command finished. I cleaned the resulting git repository a bit (deleting unneded branches, creating tags etc.) and now everything looks really nice and works well. The repository is hosted on a Linux box, and cloning that onto other Linux boxes works really well.
However, I noticed one problem: when cloning the repository onto a Windows box, some files appear to be modified when switching branches. For instance, I do this:
git clone svn://our.git.server/foo
git status # Everything is clean
git checkout -t origin/maintenance # Switch to maintenance branch
git status # Everything is clean
git checkout master # Back to master branch
git status # A few files are modified!
When doing a 'git diff', I notice that the modified files seem to differ in nothing but their line endings. When researching this a bit, we noticed that these files had accidentally been checked in using CR-LF line endings (instead of LF line endings) in Subversion, and this bug was converted into our git repository.
Is there any way to fix this issue in our repository (so far it wasn't cloned very often, so some history rewriting would be fine) without doing a 'cleanup commit' or the like? Maybe we can silently rewrite the affected objects somehow?
Alternatively, we could fix this in Subversion - and then issue the 'git svn clone' command above again. This seems to work incrementally (it would just pick up the latest line ending fix commit) but again - it creates a commit. I wonder whether I can get around that.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
事实证明，最简单的方法是在 Subversion 中修复有问题的文件，然后使用
It turned out that the easiest way was to fix the faulty files in Subversion, and then clone again using