git-svn の man ページでは、merge を使用しないことを推奨しています。""git-svn fetch and rebase (プルやマージではなく) を実行することをお勧めします"". そうは言っても、あなたは好きなことをすることができます:-)
ここには 2 つの問題があります。まず、svn はcommiterのみを格納し、git のようにパッチの作成者を格納しないことです。したがって、Y がマージをトランクにコミットすると、たとえパッチが X によって作成されたとしても、svn は彼女の名前だけを記録します。道を下って。
第二に、git は比較的新しい svn マージ機能を使用していないようです。git は活発に開発されており、常に新しい機能が追加されているため、これは一時的なものかもしれません。しかし、今のところ、それらを使用していません。
git 1.6.0.2 で試したところ、svn merge で同じ操作を行う場合と比較して情報が「失われます」。svn 1.5 では、ログと注釈のメソッドに新しい機能が追加されたため、トランクの svn log -g はマージのために次のようなものを出力します:
------------------------------------------------------------------------
r5 | Y | 2008-09-24 15:17:12 +0200 (Wed, 24 Sep 2008) | 1 line
Merged release-1.0 into trunk
------------------------------------------------------------------------
r4 | X | 2008-09-24 15:16:13 +0200 (Wed, 24 Sep 2008) | 1 line
Merged via: r5
Return 1
------------------------------------------------------------------------
r3 | X | 2008-09-24 15:15:48 +0200 (Wed, 24 Sep 2008) | 2 lines
Merged via: r5
Create a branch
ここで、Y は r5 をコミットし、ブランチの X からの変更をトランクに組み込みます。ログのフォーマットはそれほど素晴らしいものではありませんが、svn Blame -g で独自のものになります:
2 Y int main()
2 Y {
G 4 X return 1;
2 Y }
ここで、Y がトランクにのみコミットすると仮定すると、1 行が (ブランチで) X によって編集され、マージされたことがわかります。
したがって、svn 1.5.2 を使用している場合は、今のところ実際の svn クライアントとマージした方がよいでしょう。git ではマージ情報が失われますが、通常は文句を言わないほど賢いです。
更新: git 1.7.1 でこれを試して、その間に進歩があったかどうかを確認しました。悪いニュースは、git 内のマージはまだ svn:mergeinfo の値を設定git merge
しないため、続いてgit svn dcommit
svn:mergeinfo が設定されず、Subversion リポジトリが正規のソースである場合はマージ情報が失われることです (おそらくそうです)。良いニュースはgit svn clone
、より良いマージ履歴を構築するために svn:mergeinfo プロパティを読み込むことです。そのため、svn merge
正しく使用すれば (完全なブランチをマージする必要があります)、git クローンは git ユーザーには正しく見えます。