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>]

DESCRIPTION

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

git p4 clone を使用して既存のp4リポジトリから新しいGitリポジトリを作成し、1つ以上のp4デポパス(depot path)を指定します。 git p4sync を使用してp4の変更からの新しいコミットを組み込みます。 sync コマンドは、他のp4デポパスからの新しいブランチを含めるためにも使用されます。 git p4 submit を使用してGitの変更をp4に送信します。 コマンド git p4 rebase は同期を実行し、現在のブランチを更新されたp4リモートブランチにリベースします。

EXAMPLES

  • リポジトリをクローンします: 

    $ 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

COMMANDS

Clone

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

$ git p4 clone //depot/path/project

これは以下の事を行います:

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

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

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

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

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

Sync

p4リポジトリで開発が継続されていて、それらの変更をGitリポジトリに取り込むには以下を使用します:

$ git p4 sync

このコマンドは、p4の新しい変更を検出し、Gitがコミットするときにそれらをインポートします。

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

$ 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 実行中に最初にフェッチされて調べ(consult)られます。p4から直接インポートするのは、Gitリモートから変更をプルするよりもかなり遅いため、これは複数開発者環境(multi-developer environment)で役立ちます。

複数のブランチがある場合、 git p4 sync を実行すると、「BRANCH DETECTION」アルゴリズムが自動的に使用され、新しい変更を適切なブランチに分割しようとします。 これを --branch オプションでオーバーライドして、更新するブランチを1つだけ指定できます。

Rebase

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

$ git p4 rebase

Submit

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

現在の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コミットの作者(author)に応じて所有権が変更されます。このオプションには、 p4 protect を使用して付与できるp4の管理者権限が必要です。

送信する代わりに変更を保存するには、以下のように --shelve と --update-shelve を使用します:

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

Unshelve

Unshelvingは、棚上げされたP4チェンジリスト(shelved P4 changelist)を取得し、ブランチ refs/remotes/p4-unshelved/<changelist> で同等のgit commitを生成します。

git commitは、現在のoriginリビジョン(デフォルトではHEAD)を基準にして作成されます。親コミットはoriginに基づいて作成され、次にunshelveコミットはそれに基づいて作成されます。

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>

OPTIONS

General options

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

--git-dir <dir>

GIT_DIR 環境変数を設定します。 git(1) 参照。

-v
--verbose

より多くの進捗情報を提供します。

Sync options

これらのオプションは、最初の「クローン」(clone)操作と後続の「同期」(sync)操作で使用できます。

--branch <ref>

変更を refs/remotes/p4/master ではなく <ref> にインポートします。 <ref>が refs/ で始まる場合は、そのまま使用されます。それ以外の場合、 p4/ で始まらない場合は、その接頭辞が追加されます。

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

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

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

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

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

--changesfile <file>

<file> にリストされているp4変更番号(p4 change numbers)を1行に1つずつ正確にインポートします。 通常、 git p4 は、現在のp4リポジトリの状態を検査し、インポートする必要のある変更を検出します。

--silent

進捗情報を出力しません。

--detect-labels

デポパス(depot paths)に関連付けられているラベルを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>

指定されたリビジョン指定子(revision specifier)に含まれる変更の全範囲ではなく、最大で <n> 個の変更をインポートします。通常の使用法は、リビジョン指定子として @all を使用しますが、 --max-changes 1000 を使用して、リビジョン履歴全体ではなく、最後の1000リビジョンのみをインポートします。

--changes-block-size <n>

@all などのリビジョン指定子を特定の変更番号のリストに変換するときに使用する内部ブロックサイズ。変換の変更の完全なリストを見つけるために p4 changes への単一の呼び出しを使用する代わりに、 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

クライアント仕様(client spec)を使用して、p4でinterestingファイルのリストを見つけます。以下の「CLIENT SPEC」セクションを参照してください。

-/ <path>

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

Clone options

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

--destination <directory>

Gitリポジトリを作成する場所。 指定しない場合、p4デポパス(p4 depot path)の最後のコンポーネントを使用して新しいディレクトリを作成します。

--bare

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

Submit options

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

--origin <commit>

p4に送信するコミットが識別される上流の場所。デフォルトでは、これは HEAD から到達可能な最新のp4コミットです。

-M

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

--preserve-user

p4に送信する前に、p4の変更を再作成(re-author)してください。このオプションには、p4管理者権限が必要です。

--export-labels

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

-n
--dry-run

どのコミットがp4に送信されるかだけを表示します。Gitまたはp4の状態を変更しないでください。

--prepare-p4-only

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

--shelve

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

--update-shelve CHANGELIST

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

--conflict=(ask|skip|quit)

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

--branch <branch>

送信後、デフォルトの p4/master の代わりに、この名前付きブランチを同期します。詳細については、上記の「Sync options」セクションを参照してください。

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

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

--disable-rebase

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

--disable-p4sync

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

Hooks for submit

p4-pre-submit

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

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

p4-prepare-changelist

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

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

p4-changelist

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

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

p4-post-changelist

p4-post-changelist フックは、submitがP4で正常に発生した後に呼び出されます。 これはパラメーターを必要とせず、主に通知を目的としており、git p4 submitアクションの結果に影響を与えることはできません。

Rebase options

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

--import-labels

p4ラベルのインポート。

Unshelve options

--origin

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

DEPOT PATH SYNTAX

git p4 sync と gitp4 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」を参照してください。

CLIENT SPEC

p4クライアントの仕様は、 p4 client コマンドで維持され、他のフィールドの中でも、デポがクライアントリポジトリにマップされる方法を指定するビューが含まれています。 clone と sync`コマンドは、 `--use-client-spec オプションが指定されているか、または useClientSpec 変数がtrueの場合に、クライアント仕様(client spec)を参照できます。 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` によって参照されるファイル または ローカルホスト名 です。

BRANCH DETECTION

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

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

たとえば、P4リポジトリ構造が以下の場合:

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

そして、 p4 branch -o branch1 は、以下のようなビューライン(View line)を表示します:

//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 .

PERFORMANCE

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

CONFIGURATION VARIABLES

以下の構成設定を使用して、 git p4 の振る舞いを変更できます。全てを見たい時は「git-p4」セクションを参照してください。

General variables

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> で指定されるクライアント。クライアントスペック(client spec)を含んでいます。

git-p4.retries

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

Clone and sync variables

git-p4.syncFromOrigin

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

git-p4.branchUser

ブランチ検出のフェーズの一つでは、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クライアント仕様(p4 client spec)を使用する必要があることを指定します。これは、オプション --use-client-spec を指定するのと同じです。上記の「CLIENT SPEC」セクションを参照してください。 この変数はブール値であり、p4クライアントの名前ではありません。

git-p4.pathEncoding

Perforceは、元のOSによって指定されたパスのエンコーディングを保持します。 Gitは、UTF-8としてエンコードされたパスを想定しています。 この設定を使用して、 PERFORCEがパスに使用したエンコーディングをgit-p4に通知します。 このエンコーディングは、 パスのエンコーディングをUTF-8に変換するために使用されます。 例として、 Windows上のPerforceは、 パス名をエンコードするために cp1252 を使用することがよくあります。 このオプションが p4 clone リクエストに渡されると、 生成された新しい git リポジトリで永続化されます。

git-p4.metadataDecodingStrategy

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

git-p4.metadataFallbackEncoding

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

git-p4.largeFileSystem

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

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

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

git-p4.largeFileThreshold

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

git-p4.largeFileCompressedThreshold

圧縮サイズがしきい値を超えるすべてのファイルは、ラージファイルシステム(large file system)によって処理されます。このオプションを使用すると、クローン/同期プロセスの速度が低下する可能性があります。デフォルトでは、しきい値はバイト単位で定義されています。 単位を変更するには、接尾辞k、m、gを追加します。

git-p4.largeFilePush

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

git-p4.keepEmptyCommits

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

git-p4.mapUser

P4 user をGitのnameとemail addressにマッピングします。以下の形式の文字列を使用して、マッピングを作成します: 

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

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

Submit variables

git-p4.detectRenames

名前の変更(renames)を検出します。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作者(author)を反映するように変更を再作成(re-author)します。

git-p4.allowMissingP4Users

preserveUser がtrueの場合、 git p4 は通常、p4ユーザーマップで作者(author)が見つからない場合に停止(die)します。この設定は、それを気にせずに変更を送信します。

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 は終了(exit)します。このオプションは、関係なく送信を強制するために使用できます。

git-p4.attemptRCSCleanup

有効にすると、 git p4submit は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 の指定を含んでいます。

IMPLEMENTATION DETAILS

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

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

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

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

GIT

Part of the git(1) suite