Git
日本語 ▾ トピック ▾ 最新バージョン ▾ git-p4 の最終更新は 2.37.0 です

NAME

git-p4 - Perforceリポジトリとの間でインポートとサブミットを行う

SYNOPSIS

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リポジトリと対話する方法を提供します。

git p4 cloneを使用して、既存のp4リポジトリから新しい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 protectを使用して付与できるp4での管理者権限が必要です。

サブミットする代わりに変更をシェルフに格納するには、--shelveおよび--update-shelveを使用します

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

シェルフ解除

シェルフ解除は、シェルフに格納されたP4チェンジリストを取得し、ブランチrefs/remotes/p4-unshelved/<チェンジリスト>に相当する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>

オプション

一般的なオプション

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

--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の変更番号を1行に1つずつ正確にインポートします。通常、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への一連の呼び出しがあります。デフォルトのブロックサイズは500で、通常は適切です。

--keep-path

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

--use-client-spec

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

-/ <path>

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

クローンオプション

これらのオプションは、上記で説明したsyncオプションとともに、最初のcloneで使用できます。

--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変更のすべてのファイルを含む1つのコミットをインポートします。

"//depot/my/project@all"

そのデポパスの履歴の各変更に対して1つのコミットをインポートします。

"//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コマンドが適切に機能するようになります。サブミットコマンドは変数のみを調べ、コマンドラインオプションはありません。

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 に対して master という名前の refs/remotes/p4/ 内に個別のブランチが作成され、//depot/branch1 に対して depot/branch1 という名前のブランチが作成されます。

ただし、ブランチのように使用するために p4 でブランチを作成する必要はありません。ブランチの関係を自動的に推測することは難しいため、Git 設定 git-p4.branchList を使用して、ブランチの関係を明示的に識別できます。これは、単純な p4 ブランチ仕様のような "source:destination" ペアのリストであり、"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 が使用する fast-import メカニズムは、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 としてエンコードされることを期待します。この設定を使用して、git-p4 に Perforce がパスに使用したエンコーディングを伝えます。このエンコーディングは、パスを 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 としてのデコードに失敗した場合にのみ使用されます。このオプションのデフォルトは、一般的な Windows エンコーディングである cp1252 です。このオプションが 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デポの場所とチェンジ番号を示すログメッセージの末尾に1行が追加されます。この行は、後続のgit p4 sync操作で、どのp4の変更が新しいかを把握するために使用されます。

GIT

git[1]スイートの一部

scroll-to-top