3

subgitを使用して、古い svn リポジトリを git に変換しました (完全な履歴、ブランチ、タグを含む)。いくつかの最初の問題の後、私はそれを機能させ、ほぼ完全に機能しました。ブランチがトランク/マスターブランチにマージされていないように見えることを除いて:

ここに画像の説明を入力

ご覧のとおり、git は、私が緑のマスターをブランチして黒のブランチを取得したことを認識しています。しかし、このブランチがコミット時にマスターにマージされたことを認識していないようです73653d1。そのブランチを放棄し、マスター ブランチの 1 つのコミットですべてを個別に実装したようです。

これは、正しいマージがどのように見えるべきかということではありませんよね? これを修正する方法はありますか？これは歴史上約 50 件のコミットであり、参照が欠落しているように見えることに注意してください。コードは問題ありません。

4

1 に答える 1

5

そう、

r141: ^/trunk を ^/branches/restructure にコピーしました
r142: 変更した ^/branches/restructure
...
r148: 変更した ^/branches/restructure
r149: r142:148 を ^/branches/restructure から ^/trunk にマージしました

つまり、r149 で ^/branches/restructure の r141 を ^/trunk にマージしませんでした。

ご存じのとおり、Git のマージ コミットには、すべての親の全履歴が含まれます。そのため、SubGit は、マージ コミットを作成するときに、必要なすべてのリビジョンが対応するブランチにマージされたかどうかを確認します。

あなたの場合、SubGit は r141 を ^/branches/restructure の履歴のギャップとして検出したため、このブランチをマージの親として commit に追加しませんでした73653d1。

次のように主張できます。

r141 はファイルやディレクトリの変更を導入していないのに、なぜ SubGit はこのリビジョンを svn:mergeinfo に含める必要があるのでしょうか?

一般的なケースでは、単一の SVN リビジョンがブランチを作成し、その中の任意のファイルを変更することがあります。そのため、SubGit はブランチの履歴のすべてのリビジョンを引き続きチェックします。

ただし、SubGit は少し賢く、ブランチを作成するリビジョンがその中のファイルを変更するかどうかをチェックする可能性があるため、SubGit はマージコミットを自動的に作成します。将来的に実装する可能性があります。これが私たちのトラッカーの問題です。

Git で履歴を修正するには?

Subversion は既存の履歴の変更を許可しないため、欠落している r141 を ^/trunk の svn:mergeinfo プロパティに追加する新しいリビジョンを作成する必要があります。そのために次のことを検討してください。

$ svn switch ^/trunk .
$ svn merge --record-only ^/branches/restructure@148 .
$ svn commit -m 'Merged r141 of restructure changes into the trunk'

Subversion と Git リポジトリの同期を維持すると、SubGit はこのリビジョンを自動的にマージ コミットに変換します。それ以外の場合は、履歴を最初から変換するか、SubGit を同じ SVN リポジトリにもう一度インストールするだけです。

更新:
SVN 同期が不要になった場合、Git リポジトリの履歴を修正するにはどうすればよいですか?

73653d1次のコマンドを使用して、コミットから始まる Git 履歴の一部を書き換えることができます。

git filter-branch --parent-filter \
'test $GIT_COMMIT = 73653d1 && echo "-p 2ec9e8c -p 5c237f9" || cat' master

注意: 省略された , の代わりに完全なコミット ID を入れ73653d1て2ec9e8cください5c237f9。

このコマンドは、5c237f9コミットするマージの親として commit を追加する必要があり73653d1ます。

それが役立つことを願っています。

于 2012-12-10T17:20:32.647 に答える