2009-06-01 13 views
7

私の典型的なのgit-svnのワークフローは次のとおりです。この時点でなぜgit-svn dcommitは私のgitリポジトリに重複したコミットを残していますか?それを止めることはできますか?

git checkout -b story-xyz 
git commit -a -m "work" 
git commit -a -m "more work" 
git checkout master 
git svn fetch 
git merge remotes/trunk 
git checkout story-xyz 
git rebase master (sometimes with -i) 
git checkout master 
git merge story-xyz 

が、私は私のmasterstory-xyz枝が一つ以上が先にremotes/trunkのコミット、同じコミットを指しています。 remotes/trunk以降のすべてが1つの線形履歴にあります。

last svn commit [remotes/trunk] <--- work <--- more work [master, story-xyz] 

私はその後、私はすべての最新指しremotes/trunkmasterstory-xyzremotes/trunkmaster間のコミットはSubversionのリビジョンになり、単一の線形の歴史で終わる見込ま

git svn dcommit 

を実行しますリビジョンは次のようになります。

last svn commit <--- work <--- more work [master, story-xyz, remotes/trunk] 

私のSubversionリビジョンは次のとおりです私は2分岐構造になってしまいます。ブランチの共通ルートは、コミットする前のSubversion HEADです。両方のブランチには、同じdiffが含まれているという意味で、一連のコミットが含まれています。 gitのは、私がgit svn dcommitを実行する前に持っていたことをコミットし

last svn commit <--- work <--- more work [master, remotes/trunk] 
        | 
        \- work <--- more work [story-xyz] 

がメッセージをコミット私はgitで、下枝(story-xyz)にあり、gitの:ブランチstory-xyzは、他の1つのブランチ、remotes/trunkmasterの頭にありますユーザー名と電子メール、gitコミットタイムスタンプ。上のブランチ上のコミットは新しいgitコミットです。彼らは私のSubversionユーザー名、dcommitを実行した時のタイムスタンプを使用し、コミットメッセージにはgit-svn-idフィールドが追加されています。

これはすべて問題なく、作業を続けることができます。問題は、私がgitkを見て、マージされていないブランチのように見えることです。story-xyz私がmasterに合併した物語枝と、私が持っていない物語の違いを伝えるのはかなり難しいです。それを見つける最も明白な方法は、重複コミットメッセージです。私はstory-xyzブランチを削除することができましたが、gitを正しく使用していないように感じ、履歴を失ってしまいました。

git-svnはこれを停止するようなものがありません。あるいはこれは、Subversionとのやりとりがgitの力と自由を薄める方法のほんの一例ですか?

答えて

4

私はあなたが本当に何かを欠けているとは思わない。あなたは、しかし、いくつかの不必要な作業をしている可能性があります。この場合、 "もっと仕事"をコミットする2つのポインタがあり、git-svnにそれらのうちの1つを動かすように要求しています。他の人はそれがまだどこに残っています。

masterブランチは本当に必要ありません。 Git-svnはあなたがコミットしているブランチを気にしません。 IIRCでは、現在のコミットの祖先の中で最初に見つかるsvn-remoteを使用します。

私は、ワークフローの別のバージョンを提供します:

git checkout -b story-xyz remotes/trunk 
git commit -a -m "work" 
git commit -a -m "more work" 
git svn fetch 
git rebase remotes/trunk (with -i, perhaps) 
git svn dcommit 

これは、余分な枝なしであなたのツリーを与える必要があります。あなたは早送りマージに注意する必要があります。

+0

ありがとう、私は今日これを試します。これがマスターの必要性を完全に取り除くように見えるので、リモーツ/トランクの歴史は現在私たちの歴史のメインラインになると思っていますか? –

+1

あなたの場合でも、リモート/トランクの履歴は「メインライン」です。あなたの最後のグラフを見てください。マスターの歴史は、リモート/トランクの歴史と同じです。両方とも "メインライン"としても同じように有効です - リモートはそれが_shared_メインラインであるためです。 完全にマスターを削除する必要はありません。あなたはそれを歴史のいくつかの早い時点でぶら下げておくことができます。その後、たとえばあなたがする必要がある場合。 1つのコミット、あなたはマスターとsvnをチェックアウトすることができます現在の日にそれをrebaseします。 –

+0

はい、それは理にかなっています。私はあまりにも特別なことである「マスター」というアイデアに縛られていたと思う。まだあなたのワークフローを試してみる機会はありませんでしたが、期待どおりに動くなら答えを受け入れるでしょう。 –

関連する問題