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

名前

git-p4 - Perforceリポジトリからのインポートおよび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リポジトリを作成するには、git p4 cloneを使用し、1つ以上のp4デポパスを指定します。p4の変更から新しいコミットを取り込むには、git p4 syncを使用します。syncコマンドは、他のp4デポパスからの新しいブランチを含めるためにも使用されます。Gitの変更をp4にコミットするには、git p4 submitを使用します。git p4 rebaseコマンドは、同期を行い、現在のブランチを更新された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リポジトリを追加するには、git p4 syncを使用することもできます。

$ 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コミットは現在のoriginリビジョン（デフォルトではHEAD）を基準に作成されます。親コミットはoriginに基づいて作成され、その後アンシェルブコミットがそれに基づいて作成されます。

originリビジョンは"--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に1行に1つずつリストされている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/foo/bar.cは、//depot/main/からインポートされると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リフスペックを設定します。デフォルトは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コマンドで維持され、他のフィールドの中でも、デポがクライアントリポジトリにどのようにマップされるかを指定するViewを含みます。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が存在する場合、それが優先されます。それ以外の場合は、P4CLIENT環境変数、P4CONFIGによって参照されるファイル、またはローカルホスト名など、クライアントを決定するための通常のp4メカニズムが使用されます。

ブランチ検出

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

refs/remotes/p4/に、//depot/main用の別のブランチであるmasterと、//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です。再試行を無効にするには値を0に設定するか、p4のバージョンが再試行をサポートしていない場合（2012.2以前）に設定します。

クローンと同期の変数

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戦略を使用してPerforceの作者名とチェンジリストの説明をデコードする際に使用するフォールバックエンコーディングを指定します（git-p4.metadataDecodingStrategyを参照）。フォールバックエンコーディングは、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[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

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

git-p4.disableRebase

コミット後、p4/masterに対してツリーをリベースしません。

git-p4.disableP4Sync

コミット後、p4/masterをPerforceと同期しません。git-p4.disableRebaseを意味します。

実装の詳細

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

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

  • コミットにはp4クライアントが必要で、これはGitリポジトリと同じ場所にはありません。パッチは、このp4クライアントに1つずつ適用され、そこからコミットされます。

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

Git

git[1]スイートの一部

scroll-to-top