dr *_*ter 9 git newline git-svn eol core.autocrlf
我正在使用git svn,今天我遇到了一些麻烦.
我做了一段时间git svn clone,并在我的项目上工作了一段时间.几天后,我把我的工作推到了svn remote(git svn dcommit).然后我试图用TortoiseSVN检查项目,看看一切是否正确.不幸的是,一切都转换为Unix行结尾,VC6无法打开项目.
所以,我的git工作副本是CRLF,但我的svn工作副本是LF.我假设git在git commit或期间转换它git svn dcommit.
如果我设置core.autocrlf = false我的git工作副本,我是否可以假设我可以避免所有这些麻烦？这种强迫git会单独留下新线吗？还有什么需要做的才能让git svn易于使用而不会给我的同事带来麻烦吗？
(也可能有趣的是,我之前在同一台机器上使用过git svn,没有触及设置,这是第一次发生这样的事情.)
Subversion 可以对各个文件进行 EOL 转换设置。实际上，Git 也以 .gitattributes 文件的形式提供它（“text”和“eol”属性）。对于一般情况 core.autocrlf 是不够的。
如果将其设置为 false，则所有 svn:eol-style=native 的文件都将具有以 git-svn 工作副本结尾的 LF 行，这对于 Windows 来说是不需要的。
如果设置为 true，则所有行结尾都将转换为 LF，并以 LF 的形式发送到 SVN（始终）。
实际上svn:eol-style=unset应该对应于 '-text' git 属性（这意味着没有转换），svn:eol-style=LF--- 对应于 'eol=lf' 属性和svn:eol-style=CRLF--- 对应于 'eol=crlf' 属性；svn:eol-style=native与系统相关，因此可以通过无版本控制的 EOL 设置进行控制，因此相应的 git 属性是“!eol”（这意味着从core.eol.git/config 获取 EOL 设置）。
您可以使用任何能够将 svn:eol-style 转换为各个文件相应的 .gitattirbutes 值的解决方案，而不是 git-svn，反之亦然。一种解决方案是服务器端：您将SubGit安装到 SVN 存储库中，然后仅使用 SubGit 将创建的纯 Git 界面：
$ subgit install path/to/svn/repository
# Git interface with correct .gtattributes repository will appear at path/to/svn/repository/.git
# you should setup an access to it
然后在客户端克隆它，并将 core.eol 对于 Windows 设置为“crlf”，对于其他操作系统设置为“lf”（默认值为“lf”）。
$ git clone <URL> working_tree
$ cd working_tree
$ git config core.eol crlf #for Windows only
之后 Git 的行为方式将与 SVN 相同。
或者在客户端，您可以使用SmartGit：您可以用它克隆 SVN 存储库（而不是打开现有的 git-svn 存储库）——然后它将把 svn:eol-style 转换为 .gitattributes。这种情况下不需要额外的 core.eol 设置，SmartGit 会关心它。