9

私は git svn を使用していますが、今日はトラブルに遭遇しました。

私はgit svn clone自分のプロジェクトにしばらく取り組みました。数日後、自分の作業を svn リモート ( git svn dcommit) にプッシュしました。次に、TortoiseSVN を使用してプロジェクトをチェックアウトし、すべてが正しいかどうかを確認しようとしました。残念ながら、すべてが Unix の行末に変換され、VC6 はプロジェクトを開くことができませんでした。

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

core.autocrlf = falsegit 作業コピーを設定すれば、この問題をすべて回避できると思い込むのは正しいでしょうか? これにより、git は改行をそのままにしておくようになりますか? 同僚に問題を起こさずに git svn を使いやすくするために必要なことは他にありますか?

(以前、同じマシンで git svn を設定に触れずに使用したことがあり、このようなことが起こったのはこれが初めてだったことを言及することも興味深いかもしれません。)

4

1 に答える 1

0

Subversionには、個々のファイルのEOL変換設定の可能性があります。実際、Gitには.gitattributesファイル（「text」および「eol」属性）の形式でもあります。一般的なケースでは、core.autocrlfでは不十分です。

falseに設定すると、svn：eol-style = nativeのすべてのファイルのLF行がgit-svn作業コピーで終わります。これは、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設定を取得します）。

git-svnの代わりに、svn：eol-styleを個々のファイルの対応する.gitattirbutes値に、またはその逆に自動的に変換する任意のソリューションを使用できます。1つの解決策はサーバー側です。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」に設定し、他のOSの場合は「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がそれを処理します。

于 2012-08-09T15:01:57.660 に答える