このようなgit-svnとsvn CRLFの問題を回避するにはどうすればよいですか？

Question

私はgit svnを使用していますが、今日私はいくつかの問題に遭遇しました。

私はgit svn cloneをしばらくの間プロジェクトに取り組んでいました。数日後、私は自分の仕事をsvn remote（git svn dcommit）にプッシュしました。それから私はTortoiseSVNでプロジェクトをチェックアウトして、すべてが正しいかどうかを調べました。残念ながら、すべてがUnixの行末に変換され、VC6はプロジェクトを開けませんでした。

私のgit作業コピーはCRLFでしたが、私のsvn作業コピーはLFでした。私はgit commitまたはgit svn dcommitの間にgitを変換したと仮定しています。

私はgitの作業コピーにcore.autocrlf = falseを設定すると、この問題を回避できると思いますか？この強制的に改行だけを残すのでしょうか？私の同僚に問題を引き起こすことなくgit svnを使いやすくするために何か必要なことはありますか？

（それはまた、私は、設定を触れることなく、以前と同じマシン上のgitのsvnを使用している、これはこのような何かが起こったのは初めてだったことを言及するのは興味深いかもしれません。）

Answer 1

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は、Gitの属性（すなわち、NO変換を意味しない）、svn:eol-style=LF --- 'EOL = LF' 属性とsvn:eol-style=CRLFへ--- 'EOL = CRLF' 属性に '-text' に対応しなければなりません。 svn:eol-style=nativeはシステムに依存するため、バージョン管理されていないeol設定で制御できるので、対応するgit属性は '！eol'です（これは.git/configのcore.eolからのEOL設定を意味します）。

git-svnの代わりに、svn：eol-styleを個々のファイルの対応する.gitattirbutes値に変換する任意のソリューションを使用することができます。 一つの解決策は、サーバー側である：あなたのSVNリポジトリにSubGitをインストールして、ちょうど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 

次に、クライアントで、あなたがそれをクローンすると「CRLF」にcore.eolを設定しますWindowsでは 'lf'、他のOSでは 'lf'（デフォルト値は 'lf'）です。

$ git clone <URL> working_tree 
$ cd working_tree 
$ git config core.eol crlf #for Windows only 

その後、GitはSVNと同じように動作します。

また、SmartGitを使用することもできます。既存のgit-svnリポジトリを開いていない状態でSVNリポジトリを複製できます。その後、svn：eol-styleを.gitattributesに変換します。このケースでは追加のcore.eol設定は必要ありませんが、SmartGitは気にします。