2016-06-29 20 views
2

Gitにはなかった履歴を、古いバージョンの他の制御システムから遡ってコミットすることにしました。そこで私は孤児のブランチ "newroot"を作成し、他のバージョン管理システムからそれにコミットをインポートしました。次の質問Insert a commit before the root commit in Git?git rebaseの競合を以前に解決したのと同じ方法で解決しました

"newroot"ブランチは、 "master"ブランチのルートコミットと完全に一致するファイルで終了しました。問題は、私はすべてがマージの競合を解決するように要求してしまうことがあります

git rebase --onto newroot --root master 

は今、私は次のように、「newrootの」オーファン・ブランチへの「マスター」ブランチをリベースします。何年もの間に何百もの合併があります。私はそれらを手動で解決することができません。これらの合併はすでに過去に解決されていたため、本当に必要はありません。リベースは実際に内容を変更しないので(同じツリー上でリベースしているので)、Gitに「マージをリプレイ」させたい。

以前に使用した解像度と同じ解像度を使用するように指定する方法はありますか?

「rerere」がここで役立つかもしれないと私は理解しました。しかし、元々合併したときに、すでに有効にしなければならなかったでしょうか?あるいは、 "rerere"キャッシュを遡って再作成することはできますか?


私の仕事に対する別の解決策を想像することができます。何らかの理由でGitに実際にリベースせずに "newroot"と "master"ブランチを連結するように依頼する。しかし、それが可能かどうかは分かりません。

答えて

3

実際にリベースしなくても、何とか "newroot"ブランチと "master"ブランチを連結するようGitに依頼してください。しかし、それが可能かどうかは分かりません。

これはgraft pointと呼ばれ、マスター履歴を書き換えるためにfilter-branchが続きます。
this post as an exampleまたはthis questionを参照してください。リベース側で

、あなたは(マスターがリベースされているため)masterブランチの内容を使用して、任意の競合を解決するために、あなたの答えのための

git rebase --merge -s recursive -X theirs --onto newroot --root master 
+0

おかげで彼らのようなマージ戦略を試してみて、使用することができます。グラフトポイントは、私が後にした解決策のように見えます。 'filter-branch'がなぜ必要なのか、グラフトポイントに関して行うのはなぜですか? –

+1

@ MartinPrikrylグラフトポイントは、別のブランチの親として見えるブランチを作るための純粋にローカルなトリックです。マスターの各SHA1が新しい親を反映する必要があるので、そのトリックを永続的にするためにfilter-branchが必要です。最初のものから始めて(今は古いimportブランチを親として持つ)再びhttp://bugsquash.blogspot.fr/2010/03/stitching-git-histories.htmlに具体的な例を示します。 – VonC

+0

OK、グラフトポイントを追加してから、 'filter-branch'を呼び出すと、グラフトポイントが表示され、グラフトポイントに従って履歴が再作成されます。その後、グラフトポイントはもはや必要ではない。あれは正しいですか? –

関連する問題