1

このブログ投稿の手順に従って、ある git リポジトリの内容を別の git リポジトリにコピーしました。(これには、リモートの作成、フェッチ、およびパス名マップを使用した read-tree の使用が含まれます。) 問題は、後続の変更をマージしたいときに発生します。マージは、パス名のマッピングを認識しません。それを伝える方法はありますか？

2 番目のレポの内容をより大きなレポに追加するために私が従った手順は次のとおりです。

git remote add projB <github-remote-location>
git merge -s ours --no-commit projB/master
git read-tree --prefix=subdirB/ -u projB/master
git ci -m "merging projB into subdirB"

その後、git add を使用して古い「projB」レポに何か新しいものを追加し、マージされたレポで次を実行すると、楽しい結果が得られます。

git fetch projB
git pull projB SomeTag

その結果、再配置されていない場所に新しいファイルが表示されます。

4

1 に答える 1

1

簡単な答えは次のとおりです。

git pull -s subtree projB SomeTag

gitデフォルトでは、移動や名前の変更を追跡しません。たまたま類似性によっていくつかをキャッチしているように見えますが、リポジトリの奥深くではその情報を保持していません。また、新しいファイルでそのようなメタデータを推測する方法はありません。

入力したコマンドは、これらのメタデータに関して魔法のようなことは何もしません。彼らが最終的に行うことは、次のような新しいHEADコミットを作成することだけです。

  • projB/master追加の祖先として持つ (2 行目) 。ベース祖先は現在の HEAD です。線形ベースラインの通常のケースでは、最初のコミットを除いて、すべてのコミットには単一の祖先があります。複数の先祖を持つコミットは、「マージ」コミットと呼ばれます。

  • 含むすべてをprojB/master含み、サブディレクトリに移動subdirB(3 行目)

しかし、マージ コミットが作成された後 (4 行目)、それ以上のことは記憶されていません。特に、結果のツリーのどこからどのファイルが来るかではありません。

どうやらそのユースケースは、誰かがマージ戦略を書いたほど頻繁に現れ、subtreeマージされている参照がルート以外の場所にうまく適合しないかどうかをたまたま探していました。ただし、その動作は明示的に要求する必要があります。

リンク先のブログ投稿はたまたま言及していますが、一番下に隠されています。著者は TL;DR でそれを思い出すことができませんでした。このストーリーのより凝縮されたバージョンはgit docs で見つけることができます。これは Pro Git book のセクションでもあります。

于 2013-11-12T10:07:02.610 に答える