7

を実行した後git-p4 clone --use-clientspec、clientspec にエントリを追加し、追加したエントリの現在の状態を Git リポジトリにインポートしたいと考えています。

clientspec を拡張した後、agit-p4 rebaseは何もしません (おそらく、最後にコミットされた変更以降、関連する新しい変更リストがなかったため、clientspec を更新しただけです)

を試してみましたgit-p4 sync --use-client-specが、新しいヒントに最初のコミットが含まれていないため、高速インポートが失敗したと不平を言っています。

git-p4 clone新しい Git リポジトリをゼロから作成することなく、クライアントの仕様を拡張する方法はありますか?

4

2 に答える 2

5

git-p4これを書いている時点では、Perforce clientspec から追加のパスを直接インポートする方法を見つけることができませんでした。しかし、私は手動でそれを行う方法を考案し、それをgit-p4尊重していると信じています.

免責事項:以下の手順によって発生する可能性のある損害について、私は一切の責任を負いません。.git最初にツリーをバックアップすることをお勧めします。

アイデア

おっしゃるとおり、Perforce clientspec にパスを追加してgit p4 rebase最初に実行するだけでは何も起こりません。git p4 rebaseただし、 Perforceで変更された後、新しいパスがgit-p4のdepot-pathsリスト内にある場合、そのパスからファイルが追加されることに気付きました。(depot-pathsは に提供されるデポ パスの初期リストですgit p4 clone。) したがって、次のものが必要です。

  1. 新しいパスの最初のコピーを Git リポジトリに取得します。
  2. そのgit-p4最初のコピー自体を追加したと信じ込ませるため。
  3. リストgit-p4に新しいパスを含めるには。depot-paths

したがって、Perforce からファイルのコピーを同期し、Perforce から既にインポートされているファイルと整合性があることを確認してから、Git リポジトリに明示的に追加できます。

git-p4明らかに、そのdepot-pathsリストや最後にインポートされた Perforce の変更番号は、Git コミット メッセージ以外の場所には保存されないためgit-p4、独自のコミット メッセージでメタデータを複製することでだますことができます。

最後に、新しいコミットを指すようにp4/master(およびp4/HEADのエイリアスである) を移動して、今後のコマンドがそのコミットを Perforce からインポートされたものとして扱うようにすることができます。p4/mastergit p4 rebase

一歩一歩

  1. に対応するコミットを確認してくださいp4/master。ステージングまたはステージングされていない変更がないことを確認してください。もしそうなら、それらを隠してください。

  2. で使用される Perforce clientspec に新しいパスを追加しgit-p4ます。以下の手順では、これを と呼びます//depot/new/path/。

  3. 実行git logして、最後にインポートした Perforce の変更からのコミット メッセージを確認します。次のような行があります。

    [git-p4: depot-paths = "//depot/tree/": change = 12345]

    Perforce 変更番号をメモします。

  4. Perforce クライアントで、追加したパスをその変更番号に同期します。例えば：p4 sync //depot/new/path/...@12345

  5. 新しく同期されたファイルを Perforce クライアントから Git リポジトリの対応する場所に再帰的にコピーします。(シンボリックリンクがある場合は、ここで注意が必要かもしれません。)

  6. git addGit リポジトリの新しいパスで実行します。

  7. 実行しますgit commit。ほとんどの場合、コミット メッセージで必要なことを何でも言えます (例: "CLN 12345 からの //depot/new/path/ の初期インポート")。ただし、メッセージの最後に、git-p4前に確認したメタデータ行をコピーする必要があります。

    [git-p4: depot-paths = "//depot/tree/": change = 12345]

    //depot/new/path/が のサブディレクトリでない場合は//depot/tree、修正depot-pathsして新しいパスを追加する必要があります。

    [git-p4: depot-paths = "//depot/new/path/,//depot/tree/": change = 12345]

    depot-pathsリストはASCII 値でソートする必要があり//depot/foo-bar/ます (つまり、 の前に置く必要があります//depot/foo/bar/)。

  8. もう一度実行git logします。コミット メッセージの行が、インポートされた Perforce の変更の行のようになっていることを確認しgit-p4ます。コミットの SHA1 ハッシュを書き留めます。

  9. Git リポジトリのルートに移動します。編集し.git/refs/remotes/p4/masterます。リストされている古い SHA1 ハッシュを削除し、コミットの SHA1 ハッシュに置き換えます。(.git/refs/remotes/p4/master存在しない場合は.git/packed-refs、該当する行を確認して更新してください。)

これで、変更 12345 からのファイルのコピーが Git リポジトリに含まれるよう//depot/new/path/になり、今後の Perforce の変更からそれらのファイルへの変更が反映されるはずです。

その他の注意事項

  • 明らかに、新しいパスは、それらのファイルをインポートしたコミット後にのみ Git リポジトリに存在するため、git bisectその境界にまたがってそれらのファイルが含まれる場合は役に立ちません。

  • 変更されたファイルが Perforce clientspec に含まれている (およびgit-p4の内に含まれているdepot-paths) 場合、変更されたファイルは自動的に追加されるため、場合によっては、この作業をすべて回避できる可能性があります。たとえば、誰かが Perforce デポに新しいディレクトリを追加しようとしていて、そのディレクトリがdepot-pathsclientspec ではなく自分のディレクトリに既に含まれていることが事前にわかっている場合は、それを先制的に Perforce clientspec に追加することができます。実際にPerforceに追加された後、その新しいパスを自動的に取得できるはずです。

  • または、新しいパスを Perforce clientspec に追加してから、そのパス内のすべてのファイルに触れる Perforce の変更を送信することもできます。ただし、他の人に迷惑をかける可能性があるため、これを行うことはお勧めしません(そして、他の人がそれを行ったとしたら想像してみてください)。完全を期すためにのみ言及します。

于 2015-05-16T18:08:32.910 に答える