日本語 ▾ トピック ▾ 最新バージョン ▾ git-p4 は 2.50.0 で最終更新されました

名前

git-p4 - Perforce リポジトリからのインポートとコミット

概要

git p4 clone [<sync-options>] [<clone-options>] <p4-depot-path>…​
git p4 sync [<sync-options>] [<p4-depot-path>…​]
git p4 rebase
git p4 submit [<submit-options>] [<master-branch-name>]

説明

このコマンドは、Git を使用して p4 リポジトリと対話する方法を提供します。

既存の p4 リポジトリから git p4 clone を使用して新しい Git リポジトリを作成し、1 つ以上の p4 デポパスを指定します。git p4 sync を使用して、p4 変更からの新しいコミットを取り込みます。sync コマンドは、他の p4 デポパスからの新しいブランチを含めるためにも使用されます。git p4 submit を使用して、Git の変更を p4 に戻します。git p4 rebase コマンドは、sync に加えて、現在のブランチを更新された p4 リモートブランチにリベースします。

例

  • リポジトリをクローンする

    $ git p4 clone //depot/path/project

  • 新しく作成した Git リポジトリで作業する

    $ cd project
$ vi foo.h
$ git commit -a -m "edited foo.h"

  • p4 からの最近の変更で Git リポジトリを更新し、その上に作業をリベースする

    $ git p4 rebase

  • コミットを p4 に戻す

    $ git p4 submit

コマンド

クローン

一般的に、git p4 clone は、既存の p4 リポジトリから新しい Git ディレクトリを作成するために使用されます

$ git p4 clone //depot/path/project

これ

  1. project というサブディレクトリに空の Git リポジトリを作成します。

  2. 指定された p4 デポパスからヘッドリビジョンの全内容を、Git ブランチ refs/remotes/p4/master の単一のコミットにインポートします。

  3. このリモートからローカルブランチ master を作成し、チェックアウトします。

Git に p4 の履歴全体を再現するには、デポパスで @all 修飾子を使用します

$ git p4 clone //depot/path/project@all

同期

p4 リポジトリで開発が続くにつれて、それらの変更は次を使用して Git リポジトリに含めることができます

$ git p4 sync

このコマンドは、p4 で新しい変更を見つけ、それらを Git コミットとしてインポートします。

git p4 sync を使用して、既存の Git リポジトリに p4 リポジトリを追加することもできます

$ mkdir repo-git
$ cd repo-git
$ git init
$ git p4 sync //path/in/your/perforce/depot

これにより、指定されたデポが既存の Git リポジトリの refs/remotes/p4/master にインポートされます。--branch オプションを使用して、p4 コンテンツに使用する別のブランチを指定できます。

Git リポジトリにブランチ refs/remotes/origin/p4 が含まれている場合、それらは git p4 sync 時に最初にフェッチされ、参照されます。p4 から直接インポートするよりも Git リモートから変更をプルする方がはるかに遅いため、これは多開発者環境で役立ちます。

複数のブランチがある場合、git p4 sync を実行すると、「ブランチ検出」アルゴリズムが自動的に使用され、新しい変更を正しいブランチに分割しようとします。これは、--branch オプションで上書きして、更新する単一のブランチのみを指定できます。

リベース

一般的な作業パターンは、p4 デポから最新の変更をフェッチし、それらをローカルのコミットされていない変更とマージすることです。多くの場合、p4 リポジトリはすべてのコードの最終的な場所であるため、リベースワークフローが理にかなっています。このコマンドは、git p4 sync に続けて git rebase を実行し、ローカルコミットを更新された p4 変更の上に移動します。

$ git p4 rebase

送信

Git リポジトリからの変更を p4 リポジトリに戻すには、別の p4 クライアントワークスペースが必要です。これは、P4CLIENT 環境変数または Git 設定変数 git-p4.client を使用して指定する必要があります。p4 クライアントは存在している必要がありますが、クライアントルートが存在しない場合は作成され、設定されます。

現在の Git ブランチにあるが p4/master ブランチにはないすべての変更を送信するには、次を使用します

$ git p4 submit

現在のブランチ以外のブランチを指定するには、次を使用します

$ git p4 submit topicbranch

単一のコミットまたはコミットの範囲を指定するには、次を使用します

$ git p4 submit --commit <sha1>
$ git p4 submit --commit <sha1..sha1>

アップストリーム参照は通常 refs/remotes/p4/master ですが、--origin= コマンドラインオプションを使用して上書きできます。

p4 の変更は、git p4 submit を呼び出すユーザーとして作成されます。--preserve-user オプションは、Git コミットの作成者に応じて所有権を変更します。このオプションには p4 での管理者権限が必要であり、これは p4 protect を使用して付与できます。

コミットする代わりに変更をシェルフするには、--shelve と --update-shelve を使用します

$ git p4 submit --shelve
$ git p4 submit --update-shelve 1234 --update-shelve 2345

アンシェルフ

アンシェルフは、シェルフされた P4 チェンジリストを受け取り、ブランチ refs/remotes/p4-unshelved/<changelist> に同等の git コミットを生成します。

git コミットは、現在のオリジンリビジョン (デフォルトでは HEAD) に対して作成されます。オリジンに基づいて親コミットが作成され、次にそのコミットに基づいてアンシェルフコミットが作成されます。

オリジンリビジョンは「--origin」オプションで変更できます。

refs/remotes/p4-unshelved のターゲットブランチがすでに存在する場合、古いブランチは名前変更されます。

$ git p4 sync
$ git p4 unshelve 12345
$ git show p4-unshelved/12345
<submit more changes via p4 to the same files>
$ git p4 unshelve 12345
<refuses to unshelve until git is in sync with p4 again>

オプション

一般オプション

クローンを除くすべてのコマンドはこれらのオプションを受け入れます。

--git-dir <dir>

GIT_DIR 環境変数を設定します。git[1] を参照してください。

-v
--verbose

より詳細な進捗情報を提供します。

同期オプション

これらのオプションは、最初の clone およびその後の sync 操作で使用できます。

--branch <ref>

変更を refs/remotes/p4/master ではなく <ref> にインポートします。<ref> が refs/ で始まる場合、そのまま使用されます。そうでない場合、p4/ で始まらない場合は、そのプレフィックスが追加されます。

デフォルトでは、refs/ で始まらない <ref> は、リモートトラッキングブランチ (refs/remotes/ の下) の名前として扱われます。この動作は --import-local オプションで変更できます。

デフォルトの <ref> は「master」です。

この例では、新しいリモート「p4/proj2」を既存の Git リポジトリにインポートします

    $ git init
    $ git p4 sync --branch=refs/remotes/p4/proj2 //depot/proj2
--detect-branches

ブランチ検出アルゴリズムを使用して、p4 で新しいパスを見つけます。これは以下の「ブランチ検出」で説明されています。

--changesfile <file>

file に行ごとにリストされている p4 変更番号を正確にインポートします。通常、git p4 は現在の p4 リポジトリの状態を検査し、インポートすべき変更を検出します。

--silent

進捗情報を表示しません。

--detect-labels

デポパスに関連付けられたラベルを p4 に問い合わせ、それらを Git のタグとして追加します。新しいチェンジリストに関連付けられたラベルのみをインポートするため、有用性は限られています。非推奨。

--import-labels

p4 から Git にラベルをインポートします。

--import-local

デフォルトでは、p4 ブランチは refs/remotes/p4/ に格納され、git-branch[1] およびその他のコマンドによってリモート追跡ブランチとして扱われます。このオプションは代わりに p4 ブランチを refs/heads/p4/ に置きます。将来の同期操作では、refs/heads で p4 ブランチを見つけるために --import-local も指定する必要があることに注意してください。

--max-changes <n>

指定されたリビジョンスペシファイアに含まれる変更の範囲全体ではなく、最大 n 個の変更をインポートします。典型的な使用方法は、リビジョンスペシファイアとして @all を使用しますが、その後に --max-changes 1000 を使用して、リビジョン履歴全体ではなく最後の 1000 リビジョンのみをインポートします。

--changes-block-size <n>

@all のようなリビジョンスペシファイアを特定の変更番号のリストに変換するときに使用する内部ブロックサイズ。変換の変更の完全なリストを見つけるために p4 changes を 1 回呼び出す代わりに、p4 changes -m への一連の呼び出しがあり、それぞれが指定されたサイズの変更の 1 ブロックを要求します。デフォルトのブロックサイズは 500 で、通常は適切です。

--keep-path

p4 デポパスから Git へのファイル名のマッピングは、デフォルトではデポパス全体を削除することを含みます。このオプションを使用すると、完全な p4 デポパスが Git に保持されます。たとえば、//depot/main/ からインポートされたパス //depot/main/foo/bar.c は foo/bar.c になります。--keep-path を使用すると、Git パスは代わりに depot/main/foo/bar.c になります。

--use-client-spec

クライアントスペックを使用して、p4 の興味のあるファイルのリストを見つけます。以下の「クライアントスペック」セクションを参照してください。

-/ <path>

クローンまたは同期時に選択したデポパスを除外します。

クローンオプション

これらのオプションは、最初の clone で、上記の sync オプションと一緒に使用できます。

--destination <directory>

Git リポジトリを作成する場所。指定しない場合、p4 デポパスの最後のコンポーネントが新しいディレクトリを作成するために使用されます。

--bare

ベアクローンを実行します。git-clone[1] を参照してください。

送信オプション

これらのオプションを使用して、git p4 submit の動作を変更できます。

--origin <commit>

コミットを p4 に送信するために識別されるアップストリームの場所。デフォルトでは、これは HEAD から到達可能な最新の p4 コミットです。

-M

名前変更を検出します。git-diff[1] を参照してください。名前変更は、明示的な move 操作を使用して p4 で表現されます。コピーを検出するための対応するオプションはありませんが、移動とコピーの両方の変数が存在します。

--preserve-user

p4 に送信する前に p4 変更を再作成します。このオプションには p4 管理者権限が必要です。

--export-labels

Git からタグを p4 ラベルとしてエクスポートします。Git で見つかったタグは perforce 作業ディレクトリに適用されます。

-n
--dry-run

どのコミットが p4 に送信されるかのみを表示します。Git または p4 の状態は変更しません。

--prepare-p4-only

通常の送信操作と同様に、コミットを p4 ワークスペースに適用し、p4 でファイルを開き、追加し、削除します。最終的な「p4 submit」は発行せず、代わりに手動で送信または元に戻す方法に関するメッセージを表示します。このオプションは常に最初の (最も古い) コミットの後で停止します。Git タグは p4 にエクスポートされません。

--shelve

送信する代わりに、一連の棚上げされたチェンジリストを作成します。各棚上げが作成された後、関連するファイルは元に戻されるか削除されます。複数のコミットが保留中の場合、複数の棚上げが作成されます。

--update-shelve CHANGELIST

このコミットで既存の棚上げされたチェンジリストを更新します。--shelve を暗黙的に指定します。複数の棚上げされたチェンジリストに対して繰り返します。

--conflict=(ask|skip|quit)

コミットを p4 に適用する際に競合が発生する可能性があります。この場合、デフォルトの動作 ("ask") は、このコミットをスキップして続行するか、終了するかを尋ねます。このオプションを使用すると、プロンプトをバイパスして、競合するコミットを自動的にスキップするか、プロンプトなしでコミットの適用を終了することができます。

--branch <branch>

送信後、デフォルトの p4/master ではなく、この指定されたブランチを同期します。詳細については、上記の「同期オプション」セクションを参照してください。

--commit (<sha1>|<sha1>..<sha1>)

現在の Git ブランチにある変更の完全なリストではなく、指定されたコミットまたはコミットの範囲のみを送信します。

--disable-rebase

すべてのコミットが正常に送信された後の自動リベースを無効にします。git-p4.disableRebase でも設定できます。

--disable-p4sync

コミットが送信された後、Perforce から p4/master の自動同期を無効にします。--disable-rebase を暗黙的に指定します。git-p4.disableP4Sync でも設定できます。可能であれば、origin/master との同期は続行されます。

送信のフック

p4-pre-submit

p4-pre-submit フックは、存在し、実行可能であれば実行されます。このフックはパラメータを受け取らず、標準入力からも何も受け取りません。このスクリプトから非ゼロのステータスで終了すると、git-p4 submit の起動が阻止されます。これは --no-verify コマンドラインオプションでバイパスできます。

1つの使用シナリオは、フックで単体テストを実行することです。

p4-prepare-changelist

p4-prepare-changelist フックは、デフォルトのチェンジリストメッセージの準備直後、エディターが起動する前に実行されます。これは、チェンジリストテキストを含むファイルの名前を1つのパラメータとして受け取ります。スクリプトから非ゼロのステータスで終了すると、プロセスは中止されます。

このフックの目的は、メッセージファイルをその場で編集することであり、--no-verify オプションによって抑制されません。このフックは --prepare-p4-only が設定されている場合でも呼び出されます。

p4-changelist

p4-changelist フックは、ユーザーがチェンジリストメッセージを編集した後に実行されます。--no-verify オプションでバイパスできます。提案されたチェンジリストテキストを保持するファイルの名前を単一のパラメータとして受け取ります。非ゼロのステータスで終了すると、コマンドは中止されます。

このフックはチェンジリストファイルを編集でき、テキストをプロジェクトの標準形式に正規化するために使用できます。また、メッセージファイルを検査した後、送信を拒否するためにも使用できます。

p4-post-changelist

p4-post-changelist フックは、P4 での送信が正常に完了した後に呼び出されます。これはパラメータを受け取らず、主に通知を目的としており、git p4 submit アクションの結果には影響しません。

リベースオプション

これらのオプションを使用して、git p4 rebase の動作を変更できます。

--import-labels

p4 ラベルをインポートします。

アンシェルフオプション

--origin

棚上げされた P4 チェンジリストと比較する git refspec を設定します。デフォルトは p4/master です。

デポパス構文

git p4 sync および git p4 clone の p4 デポパス引数は、1 つ以上のスペース区切りの p4 デポパスで、末尾にオプションの p4 リビジョンスペシファイアが付加されます。

"//depot/my/project"

そのツリー下の #head 変更におけるすべてのファイルを含むコミットをインポートします。

"//depot/my/project@all"

そのデポパスの履歴における各変更ごとにコミットをインポートします。

"//depot/my/project@1,6"

変更 1 から 6 のみをインポートします。

"//depot/proj1@all //depot/proj2@all"

両方の指定されたデポパスからのすべての変更を単一のリポジトリにインポートします。これらのディレクトリ以下のファイルのみが含まれます。Git には「proj1」および「proj2」ごとのサブディレクトリはありません。複数のデポパスを指定する場合は --destination オプションを使用する必要があります。リビジョンスペシファイアは各デポパスで同一に指定する必要があります。デポパスに同じ名前のファイルがある場合、最も最近更新されたバージョンのファイルを持つパスが Git に表示されます。

p4 リビジョンスペシファイアの完全な構文については、p4 help revisions を参照してください。

クライアントスペック

p4 クライアント仕様は p4 client コマンドで管理され、他のフィールドの中でも、デポがクライアントリポジトリにどのようにマッピングされるかを指定するビューを含みます。clone および sync コマンドは、--use-client-spec オプションが指定された場合、または useClientSpec 変数が true の場合に、クライアント仕様を参照できます。git p4 clone の後、useClientSpec 変数はリポジトリ設定ファイルに自動的に設定されます。これにより、将来の git p4 submit コマンドが正しく機能します。submit コマンドは変数のみを調べ、コマンドラインオプションはありません。

p4 ビューの完全な構文は p4 help views で文書化されています。git p4 はビュー構文のサブセットのみを認識しています。複数行マッピング、+ を使用したオーバーレイ、- を使用した除外、空白を囲む二重引用符を理解します。使用可能なワイルドカードのうち、git p4 は …​ のみを処理し、パスの末尾にある場合のみ処理します。git p4 は、未処理のワイルドカードに遭遇すると不平を言います。

オーバーラップマッピングの実装にバグが存在します。複数のデポパスがオーバーレイを通じてリポジトリ内の同じ場所にマップされる場合、git p4 は間違ったものを選択する可能性があります。これは、git p4 のためだけにクライアントスペックを割り当てない限り、解決が困難です。

クライアントの名前は複数の方法で git p4 に指定できます。git-p4.client 変数が存在する場合は優先されます。それ以外の場合は、クライアントを決定するための通常の p4 メカニズムが使用されます。P4CLIENT 環境変数、P4CONFIG で参照されるファイル、またはローカルホスト名です。

ブランチ検出

P4 は Git と同じブランチの概念を持っていません。代わりに、p4 はコンテンツをディレクトリツリーとして整理し、慣例により異なる論理ブランチはツリー内の異なる場所にあります。p4 branch コマンドは、ツリー内の異なる領域間のマッピングを維持し、関連するコンテンツを示すために使用されます。git p4 はこれらのマッピングを使用してブランチの関係を決定できます。

関心のあるすべてのブランチが単一のデポパスのサブディレクトリとして存在するリポジトリがある場合、クローンまたは同期時に --detect-branches を使用して、git p4 に p4 のサブディレクトリを自動的に見つけさせ、これらを Git のブランチとして生成させることができます。

たとえば、P4 リポジトリ構造が

//depot/main/...
//depot/branch1/...

そして「p4 branch -o branch1」が次のような View 行を表示する場合

//depot/main/... //depot/branch1/...

この git p4 clone コマンドは

git p4 clone --detect-branches //depot@all

//depot/main のために refs/remotes/p4/ に master という個別のブランチを生成し、//depot/branch1 のために depot/branch1 というブランチを生成します。

しかし、ブランチのように使用するために p4 でブランチを作成する必要はありません。ブランチの関係を自動的に推測することは困難であるため、Git 設定 git-p4.branchList を使用してブランチの関係を明示的に識別できます。これは、「source:destination」ペアのリストであり、単純な p4 ブランチ仕様のように、「source」と「destination」は p4 リポジトリのパス要素です。上記の例は p4 ブランチの存在に依存していました。p4 ブランチがない場合でも、同じ結果は次で発生します。

git init depot
cd depot
git config git-p4.branchList main:branch1
git p4 clone --detect-branches //depot@all .

パフォーマンス

git p4 が使用する高速インポートメカニズムは、git p4 sync の呼び出しごとに 1 つのパックファイルを作成します。通常、Git のガベージ圧縮 (git-gc[1]) はこれらを自動的に少数のパックファイルに圧縮しますが、git repack -adf を明示的に呼び出すことでパフォーマンスが向上する場合があります。

設定変数

以下の設定を使用して、git p4 の動作を変更できます。それらはすべて git-p4 セクションにあります。

一般変数

git-p4.user

すべての p4 コマンドに -u <user> オプションとして指定されたユーザー。P4USER 環境変数を使用することもできます。

git-p4.password

すべての p4 コマンドに -P <password> オプションとして指定されたパスワード。P4PASS 環境変数を使用することもできます。

git-p4.port

すべての p4 コマンドに -p <port> オプションとして指定されたポート。P4PORT 環境変数を使用することもできます。

git-p4.host

すべての p4 コマンドに -h <host> オプションとして指定されたホスト。P4HOST 環境変数を使用することもできます。

git-p4.client

クライアント仕様を含む、すべての p4 コマンドに -c <client> オプションとして指定されたクライアント。

git-p4.retries

ネットワークがタイムアウトした場合に p4 コマンド (特に p4 sync) を再試行する回数を指定します。デフォルト値は 3 です。再試行を無効にするか、p4 のバージョンが再試行をサポートしていない場合 (2012.2 より前) は 0 に設定します。

クローンおよび同期変数

git-p4.syncFromOrigin

他の Git リポジトリからコミットをインポートする方が p4 からインポートするよりもはるかに高速であるため、Git リモートで最初に p4 変更を見つけるメカニズムが存在します。refs/remote/origin/p4 の下にブランチが存在する場合、それらは p4 から同期する際にフェッチされ、使用されます。この変数を false に設定してこの動作を無効にすることができます。

git-p4.branchUser

ブランチ検出の段階の1つは、p4 ブランチを調べて新しいブランチをインポートすることです。デフォルトでは、すべてのブランチが検査されます。このオプションは、検索を変数で指定された単一のユーザーが所有するブランチに限定します。

git-p4.branchList

ブランチ検出が有効になっている場合にインポートされるブランチのリスト。各エントリは、コロン (:) で区切られたブランチ名のペアである必要があります。この例では、branchA と branchB の両方が main から作成されたことを宣言しています。

git config       git-p4.branchList main:branchA
git config --add git-p4.branchList main:branchB
git-p4.ignoredP4Labels

無視する p4 ラベルのリスト。これは、インポートできないラベルが検出されると自動的に構築されます。

git-p4.importLabels

--import-labels に従って、p4 ラベルを git にインポートします。

git-p4.labelImportRegexp

この正規表現に一致する p4 ラベルのみがインポートされます。デフォルト値は [a-zA-Z0-9_\-.]+$ です。

git-p4.useClientSpec

p4 クライアントスペックを使用して、関心のある p4 デポパスを識別することを指定します。これは、--use-client-spec オプションを指定することと同じです。上記の「クライアントスペック」セクションを参照してください。この変数はブール値であり、p4 クライアントの名前ではありません。

git-p4.pathEncoding

Perforce は、元の OS で指定されたパスのエンコーディングを保持します。Git は UTF-8 でエンコードされたパスを期待します。この設定を使用して、Perforce がパスにどのエンコーディングを使用したかを git-p4 に伝えます。このエンコーディングは、パスを UTF-8 にトランスコードするために使用されます。たとえば、Windows の Perforce は、パス名に「cp1252」を使用することがよくあります。このオプションが p4 クローン要求に渡されると、結果の新しい git リポジトリに永続化されます。

git-p4.metadataDecodingStrategy

Perforce は、チェンジリストの説明とユーザーのフルネームのエンコーディングを、特定の OS のクライアントが保存したとおりに保持します。p4v クライアントは OS ローカルのエンコーディングを使用するため、異なるユーザーが同じデポ内で異なるチェンジリストの説明やユーザーのフルネームを異なるエンコーディングで保存してしまう可能性があります。Git はコミットメッセージや作成者名の不整合な/誤ったエンコーディングを許容しますが、それらが utf-8 で指定されることを期待しています。git-p4 は、Perforce のエンコーディングの不確実性を処理するために 3 つの異なるデコード戦略を使用できます。passthrough は、元のバイトを Perforce から git にそのまま渡すだけで、Perforce データが utf-8 以外のエンコーディングである場合に、使用可能だが誤ってエンコードされたデータを作成します。strict は、Perforce データが utf-8 でエンコードされていることを期待し、これが真ではない場合にインポートに失敗します。fallback は、データを utf-8 として解釈しようと試み、それが失敗した場合は、セカンダリエンコーディング (デフォルトでは一般的な Windows エンコーディング cp-1252) を使用するようにフォールバックし、フォールバックエンコーディングでのデコードも失敗した場合は上位範囲のバイトをエスケープします。python2 では、歴史的な理由からデフォルト戦略は passthrough であり、python3 ではデフォルトは fallback です。strict が選択され、デコードが失敗した場合、エラーメッセージは回避策としてこの設定パラメータの変更を提案します。このオプションが p4 クローン要求に渡されると、結果の新しい git リポジトリに永続化されます。

git-p4.metadataFallbackEncoding

fallback 戦略 (git-p4.metadataDecodingStrategy を参照) を使用して Perforce の作成者名とチェンジリストの説明をデコードする際に使用するフォールバックエンコーディングを指定します。フォールバックエンコーディングは、utf-8 としてのデコードが失敗した場合にのみ使用されます。このオプションのデフォルトは cp1252 (一般的な Windows エンコーディング) です。このオプションが p4 クローン要求に渡されると、結果の新しい git リポジトリに永続化されます。

git-p4.largeFileSystem

大きな (バイナリ) ファイルに使用されるシステムを指定します。大きなファイルシステムは git p4 submit コマンドをサポートしていないことに注意してください。現在実装されているのは Git LFS のみです (詳細については https://git-lfs.github.com/ を参照してください)。このオプションを使用するには、Git LFS コマンドライン拡張機能をダウンロードしてインストールし、次のように設定してください。

git config       git-p4.largeFileSystem GitLFS
git-p4.largeFileExtensions

リスト内のファイル拡張子に一致するすべてのファイルは、大規模ファイルシステムによって処理されます。拡張子に . を付けないでください。

git-p4.largeFileThreshold

しきい値を超える非圧縮サイズのすべてのファイルは、大規模ファイルシステムによって処理されます。デフォルトでは、しきい値はバイト単位で定義されます。単位を変更するには、接尾辞 k、m、または g を追加します。

git-p4.largeFileCompressedThreshold

しきい値を超える圧縮サイズのすべてのファイルは、大規模ファイルシステムによって処理されます。このオプションは、クローン/同期プロセスを遅くする可能性があります。デフォルトでは、しきい値はバイト単位で定義されます。単位を変更するには、接尾辞 k、m、または g を追加します。

git-p4.largeFilePush

大きなファイルがサーバーに自動的にプッシュされるかどうかを定義するブール変数。

git-p4.keepEmptyCommits

このブールオプションが true に設定されている場合、除外されたファイルのみを含むチェンジリストは空のコミットとしてインポートされます。

git-p4.mapUser

P4 ユーザーを Git の名前とメールアドレスにマッピングします。マッピングを作成するには、次の形式の文字列を使用します。

git config --add git-p4.mapUser "p4user = First Last <mail@address.com>"

マッピングは P4 からのユーザー情報を上書きします。複数の P4 ユーザーのマッピングを定義できます。

送信変数

git-p4.detectRenames

名前変更を検出します。git-diff[1] を参照してください。これは、true、false、または git diff -M が期待するスコアになります。

git-p4.detectCopies

コピーを検出します。git-diff[1] を参照してください。これは、true、false、または git diff -C が期待するスコアになります。

git-p4.detectCopiesHarder

コピーをより厳密に検出します。git-diff[1] を参照してください。ブール値。

git-p4.preserveUser

送信時に、git p4 submit を呼び出すユーザーに関係なく、Git の作成者を反映するように変更を再作成します。

git-p4.allowMissingP4Users

preserveUser が true の場合、git p4 は通常、p4 ユーザーマップで作成者を見つけられないと終了します。この設定は、状況に関わらず変更を送信します。

git-p4.skipSubmitEdit

送信プロセスは、各 p4 変更が送信される前にエディターを呼び出します。ただし、この設定が true の場合、編集ステップはスキップされます。

git-p4.skipSubmitEditCheck

p4 変更メッセージを編集した後、git p4 はファイル変更時刻を見て説明が本当に変更されたことを確認します。このオプションはそのテストを無効にします。

git-p4.allowSubmit

デフォルトでは、任意のブランチを git p4 submit 操作のソースとして使用できます。この設定変数が設定されている場合、指定されたブランチのみを送信ソースとして使用できます。ブランチ名は短い名前 (「refs/heads/」なし) でなければならず、スペースなしでコンマ (「,」) で区切る必要があります。

git-p4.skipUserNameCheck

git p4 submit を実行しているユーザーが p4 ユーザーマップに存在しない場合、git p4 は終了します。このオプションは、状況に関わらず送信を強制するために使用できます。

git-p4.attemptRCSCleanup

有効にすると、git p4 submit は RCS キーワード ($Header$ など) のクリーンアップを試みます。これらがないと、マージの競合が発生し、コミットが進まなくなります。このオプションは現在、実験的と見なされるべきです。

git-p4.exportLabels

--export-labels に従って、Git タグを p4 ラベルにエクスポートします。

git-p4.labelExportRegexp

この正規表現に一致する p4 ラベルのみがエクスポートされます。デフォルト値は [a-zA-Z0-9_\-.]+$ です。

git-p4.conflict

--conflict に従って、p4 との競合が見つかった場合の送信動作を指定します。デフォルトの動作は ask です。

git-p4.disableRebase

送信後にツリーを p4/master に対してリベースしません。

git-p4.disableP4Sync

コミットが送信された後、p4/master を Perforce と同期しません。git-p4.disableRebase を暗黙的に指定します。

実装の詳細

  • p4 からのチェンジセットは Git の fast-import を使用してインポートされます。

  • クローンまたは同期には p4 クライアントは不要です。ファイルの内容は p4 print を使用して収集されます。

  • 送信には p4 クライアントが必要で、これは Git リポジトリとは別の場所にあります。パッチは、一度に1つずつこの p4 クライアントに適用され、そこから送信されます。

  • git p4 によってインポートされた各コミットは、ログメッセージの末尾に p4 デポの場所と変更番号を示す行を持っています。この行は、その後の git p4 sync 操作によって、どの p4 変更が新しいかを知るために使用されます。

GIT

git[1]スイートの一部

scroll-to-top