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

名前

githooks - Gitが使用するフック

概要

$GIT_DIR/hooks/* (または `git config core.hooksPath`/*)

説明

フックは、Gitの実行中に特定のポイントでアクションをトリガーするために、フックディレクトリに配置できるプログラムです。実行可能ビットが設定されていないフックは無視されます。

デフォルトでは、フックディレクトリは $GIT_DIR/hooks ですが、core.hooksPath 設定変数 ( git-config[1] を参照) を介して変更できます。

Gitがフックを呼び出す前に、bareリポジトリでは作業ディレクトリを$GIT_DIRに、non-bareリポジトリでは作業ツリーのルートに変更します。プッシュ中にトリガーされるフック (pre-receiveupdatepost-receivepost-updatepush-to-checkout) は例外で、$GIT_DIRで常に実行されます。

GIT_DIRGIT_WORK_TREE などの環境変数はエクスポートされるため、フックによって実行されるGitコマンドはリポジトリを正しく見つけることができます。フックが外部リポジトリまたは同じリポジトリの異なる作業ツリーでGitコマンドを呼び出す必要がある場合は、これらの環境変数をクリアして、外部の場所でのGit操作と干渉しないようにする必要があります。例えば

local_desc=$(git describe)
foreign_desc=$(unset $(git rev-parse --local-env-vars); git -C ../foreign-repo describe)

フックは、環境、コマンドライン引数、および標準入力から引数を受け取ることができます。詳細については、以下の各フックのドキュメントを参照してください。

git init は、その設定に応じて、フックを新しいリポジトリにコピーする場合があります。詳細については、git-init[1] の「テンプレートディレクトリ」セクションを参照してください。このドキュメントの残りの部分で「デフォルトフック」と言及されている場合は、Gitに付属のデフォルトテンプレートについて説明しています。

現在サポートされているフックは以下のとおりです。

フック

applypatch-msg

このフックは git-am[1] によって呼び出されます。これは、提案されたコミットログメッセージを保持するファイルのパスを単一の引数として受け取ります。非ゼロのステータスで終了すると、パッチが適用される前に git am は中止されます。

フックはメッセージファイルをその場で編集することができ、メッセージをプロジェクト標準形式に正規化するために使用できます。また、メッセージファイルを検査した後にコミットを拒否するためにも使用できます。

デフォルトの applypatch-msg フックは、有効になっている場合、commit-msg フックが有効になっている場合は、それを実行します。

pre-applypatch

このフックは git-am[1] によって呼び出されます。パラメータは受け取らず、パッチが適用された後、コミットが作成される前に呼び出されます。

非ゼロのステータスで終了した場合、パッチ適用後も作業ツリーはコミットされません。

現在の作業ツリーを検査し、特定のテストに合格しない場合にコミットの作成を拒否するために使用できます。

デフォルトの pre-applypatch フックは、有効になっている場合、pre-commit フックが有効になっている場合は、それを実行します。

post-applypatch

このフックは git-am[1] によって呼び出されます。パラメータは受け取らず、パッチが適用され、コミットが作成された後に呼び出されます。

このフックは主に通知を目的としており、git am の結果に影響を与えることはできません。

pre-commit

このフックは git-commit[1] によって呼び出され、--no-verify オプションでバイパスできます。パラメータは受け取らず、提案されたコミットログメッセージを取得し、コミットを作成する前に呼び出されます。このスクリプトが非ゼロのステータスで終了すると、コミットが作成される前に git commit コマンドが中止されます。

デフォルトの pre-commit フックは、有効になっている場合、末尾に空白を含む行の導入を検出し、そのような行が見つかった場合にコミットを中止します。

コミットメッセージを変更するためにエディタが起動されない場合、すべての git commit フックは環境変数 GIT_EDITOR=: を設定して呼び出されます。

デフォルトの pre-commit フックは、有効になっており、hooks.allownonascii 設定オプションが設定されていないか false に設定されている場合、非ASCIIファイル名の使用を防ぎます。

pre-merge-commit

このフックは git-merge[1] によって呼び出され、--no-verify オプションでバイパスできます。パラメータは受け取らず、マージが正常に実行され、コミットを作成するための提案されたコミットログメッセージを取得する前に呼び出されます。このスクリプトが非ゼロのステータスで終了すると、コミットが作成される前に git merge コマンドが中止されます。

デフォルトの pre-merge-commit フックは、有効になっている場合、pre-commit フックが有効になっている場合は、それを実行します。

コミットメッセージを変更するためにエディタが起動されない場合、このフックは環境変数 GIT_EDITOR=: を設定して呼び出されます。

マージが自動的に実行できない場合、競合を解決し、結果を個別にコミットする必要があります (git-merge[1] を参照)。その時点で、このフックは実行されませんが、pre-commit フックが有効になっている場合は実行されます。

prepare-commit-msg

このフックは git-commit[1] によって、デフォルトのログメッセージを準備した直後、エディタが起動される前に呼び出されます。

これは1から3つのパラメータを受け取ります。最初のパラメータはコミットログメッセージを含むファイルの名前です。2番目のパラメータはコミットメッセージのソースであり、次のいずれかになります。message ( -m または -F オプションが指定された場合); template ( -t オプションが指定された場合、または設定オプション commit.template が設定されている場合); merge (コミットがマージである場合、または .git/MERGE_MSG ファイルが存在する場合); squash ( .git/SQUASH_MSG ファイルが存在する場合); または commit、その後にコミットオブジェクト名 ( -c-C または --amend オプションが指定された場合)。

終了ステータスが非ゼロの場合、git commit は中止されます。

このフックの目的は、メッセージファイルをその場で編集することであり、--no-verify オプションによって抑制されません。非ゼロの終了は、フックの失敗とコミットの中止を意味します。pre-commit フックの代わりとして使用すべきではありません。

Gitに付属のサンプル prepare-commit-msg フックは、コミットテンプレートのコメント部分にあるヘルプメッセージを削除します。

commit-msg

このフックは git-commit[1] および git-merge[1] によって呼び出され、--no-verify オプションでバイパスできます。これは、提案されたコミットログメッセージを保持するファイルのパスを単一の引数として受け取ります。非ゼロのステータスで終了すると、コマンドは中止されます。

フックはメッセージファイルをその場で編集することができ、メッセージをプロジェクト標準形式に正規化するために使用できます。また、メッセージファイルを検査した後にコミットを拒否するためにも使用できます。

デフォルトの commit-msg フックは、有効になっている場合、重複する Signed-off-by トレーラーを検出し、それが見つかった場合にコミットを中止します。

post-commit

このフックは git-commit[1] によって呼び出されます。パラメータは受け取らず、コミットが作成された後に呼び出されます。

このフックは主に通知を目的としており、git commit の結果に影響を与えることはできません。

pre-rebase

このフックは git-rebase[1] によって呼び出され、ブランチがリベースされるのを防ぐために使用できます。フックは1つまたは2つのパラメータで呼び出される場合があります。最初のパラメータは、シリーズがフォークされた upstream です。2番目のパラメータはリベースされているブランチであり、現在のブランチをリベースしている場合は設定されません。

post-checkout

このフックは、ワークツリーが更新された後に git-checkout[1] または git-switch[1] が実行されたときに呼び出されます。フックには3つのパラメータが与えられます。前のHEADのリファレンス、新しいHEADのリファレンス (変更されている場合とされていない場合がある)、およびチェックアウトがブランチチェックアウト (ブランチの変更、フラグ=1) またはファイルチェックアウト (インデックスからファイルを取得、フラグ=0) であったかを示すフラグです。このフックは git switch または git checkout の結果に影響を与えることはできませんが、フックの終了ステータスはこれらの2つのコマンドの終了ステータスになります。

--no-checkout (-n) オプションが使用されない限り、git-clone[1] の後にも実行されます。フックに与えられる最初のパラメータはnull-ref、2番目のパラメータは新しいHEADのリファレンス、フラグは常に1です。git worktree add も同様ですが、--no-checkout が使用されない限りです。

このフックは、リポジトリの有効性チェックを実行したり、異なる場合は前のHEADとの差を自動表示したり、作業ディレクトリのメタデータプロパティを設定したりするために使用できます。

post-merge

このフックは、ローカルリポジトリで git pull が行われたときに発生する git-merge[1] によって呼び出されます。フックは単一のパラメータを受け取ります。実行されたマージがスカッシュマージであったかどうかを指定するステータスフラグです。このフックは git merge の結果に影響を与えることはできず、競合のためにマージが失敗した場合は実行されません。

このフックは、対応するpre-commitフックと組み合わせて使用​​し、作業ツリーに関連付けられたあらゆる形式のメタデータ (例: 権限/所有権、ACLSなど) を保存および復元できます。これを実行する方法の例については、contrib/hooks/setgitperms.perl を参照してください。

pre-push

このフックは git-push[1] によって呼び出され、プッシュが行われるのを防ぐために使用できます。フックは、宛先リモートの名前と場所を提供する2つのパラメータで呼び出されます。名前付きリモートが使用されていない場合、両方の値は同じになります。

プッシュされる内容に関する情報は、フックの標準入力に次の形式の行で提供されます。

<local-ref> SP <local-object-name> SP <remote-ref> SP <remote-object-name> LF

例えば、コマンド git push origin master:foreign が実行された場合、フックは次のような行を受け取ります。

refs/heads/master 67890 refs/heads/foreign 12345

ただし、完全なオブジェクト名が提供されます。外部参照がまだ存在しない場合、<remote-object-name> はすべてゼロのオブジェクト名になります。参照が削除される場合、<local-ref>(delete) として提供され、<local-object-name> はすべてゼロのオブジェクト名になります。ローカルコミットが展開可能な名前以外のもの ( HEAD~ やオブジェクト名など) で指定された場合、元々与えられたとおりに提供されます。

このフックが非ゼロのステータスで終了した場合、git push は何もプッシュせずに中止されます。プッシュが拒否された理由に関する情報は、標準エラーに出力することでユーザーに送信できます。

pre-receive

このフックは git-receive-pack[1]git push に応答し、リポジトリ内の参照を更新するときに呼び出されます。リモートリポジトリの参照の更新を開始する直前に、pre-receive フックが呼び出されます。その終了ステータスは、更新の成功または失敗を決定します。

このフックは、受信操作ごとに1回実行されます。引数は受け取りませんが、更新される各参照について、標準入力に次の形式の行を受け取ります。

<old-oid> SP <new-oid> SP <ref-name> LF

<old-oid> は参照に格納されている古いオブジェクト名、<new-oid> は参照に格納される新しいオブジェクト名、<ref-name> は参照の完全名です。新しい参照を作成する場合、<old-oid> はすべてゼロのオブジェクト名です。

フックが非ゼロのステータスで終了した場合、どの参照も更新されません。フックがゼロで終了した場合でも、個々の参照の更新は update フックによって妨げられる可能性があります。

標準出力と標準エラー出力の両方が、反対側の git send-pack に転送されるため、ユーザーにメッセージを echo するだけで済みます。

git push --push-option=... のコマンドラインで指定されたプッシュオプションの数は、環境変数 GIT_PUSH_OPTION_COUNT から読み取ることができ、オプション自体は GIT_PUSH_OPTION_0GIT_PUSH_OPTION_1、…​ に見られます。プッシュオプションフェーズを使用しないようにネゴシエートされた場合、環境変数は設定されません。クライアントがプッシュオプションの使用を選択したが、何も送信しない場合、カウント変数はゼロ、GIT_PUSH_OPTION_COUNT=0 に設定されます。

いくつかの注意点については、git-receive-pack[1] の「Quarantine Environment」セクションを参照してください。

update

このフックは git-receive-pack[1]git push に応答し、リポジトリ内の参照を更新するときに呼び出されます。リモートリポジトリの参照を更新する直前に、update フックが呼び出されます。その終了ステータスは、参照更新の成功または失敗を決定します。

このフックは、更新される各参照に対して1回実行され、3つのパラメータを受け取ります。

  • 更新される参照の名前、

  • 参照に格納されている古いオブジェクト名、

  • および参照に格納される新しいオブジェクト名です。

update フックがゼロで終了すると、参照を更新できます。非ゼロのステータスで終了すると、git receive-pack がその参照を更新するのを防ぎます。

このフックは、オブジェクト名が古いオブジェクト名で指定されたコミットオブジェクトの子孫であるコミットオブジェクトであることを確認することで、特定の参照への *強制* 更新を防ぐために使用できます。つまり、「fast-forward only」ポリシーを強制するためです。

また、old..new ステータスをログに記録するためにも使用できます。ただし、ブランチの完全なセットは認識しないため、素朴に使用すると参照ごとに1通のメールが送信されてしまいます。post-receive フックの方が適しています。

ユーザーのアクセスをワイヤ経由の Git コマンドのみに制限する環境では、このフックを使用してファイルシステムの所有権やグループメンバーシップに依存せずにアクセス制御を実装できます。ユーザーのアクセスを Git コマンドのみに制限するためにログインシェルを使用する方法については、git-shell[1] を参照してください。

標準出力と標準エラー出力の両方が、反対側の git send-pack に転送されるため、ユーザーにメッセージを echo するだけで済みます。

デフォルトの update フックは、有効になっている場合、—​および hooks.allowunannotated 設定オプションが設定されていないか false に設定されている場合—​注釈なしタグがプッシュされるのを防ぎます。

proc-receive

このフックは git-receive-pack[1] によって呼び出されます。サーバーが複数値の設定変数 receive.procReceiveRefs を設定しており、receive-pack に送信されたコマンドが一致する参照名を持っている場合、これらのコマンドは内部の execute_commands() 関数ではなく、このフックによって実行されます。このフックは、関連する参照を更新し、結果を receive-pack に報告する責任があります。

このフックは、受信操作ごとに1回実行されます。引数は受け取りませんが、pkt-line 形式のプロトコルを使用して receive-pack と通信し、コマンド、プッシュオプションを読み取り、結果を送信します。以下のプロトコルの例では、文字 Sreceive-pack を表し、文字 H はこのフックを表します。

# Version and features negotiation.
S: PKT-LINE(version=1\0push-options atomic...)
S: flush-pkt
H: PKT-LINE(version=1\0push-options...)
H: flush-pkt
# Send commands from server to the hook.
S: PKT-LINE(<old-oid> <new-oid> <ref>)
S: ... ...
S: flush-pkt
# Send push-options only if the 'push-options' feature is enabled.
S: PKT-LINE(push-option)
S: ... ...
S: flush-pkt
# Receive results from the hook.
# OK, run this command successfully.
H: PKT-LINE(ok <ref>)
# NO, I reject it.
H: PKT-LINE(ng <ref> <reason>)
# Fall through, let 'receive-pack' execute it.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option fall-through)
# OK, but has an alternate reference.  The alternate reference name
# and other status can be given in option directives.
H: PKT-LINE(ok <ref>)
H: PKT-LINE(option refname <refname>)
H: PKT-LINE(option old-oid <old-oid>)
H: PKT-LINE(option new-oid <new-oid>)
H: PKT-LINE(option forced-update)
H: ... ...
H: flush-pkt

proc-receive フックの各コマンドは擬似参照を指すことができ、常に old-oid としてゼロを古いオブジェクト名として持ちますが、proc-receive フックは代替参照を更新でき、代替参照はすでに非ゼロの old-oid で存在している可能性があります。この場合、このフックは「option」ディレクティブを使用して、先頭の「ok」ディレクティブで指定された参照の拡張属性を報告します。

このフックのコマンドのレポートは、入力と同じ順序である必要があります。proc-receive フックの終了ステータスは、アトミックプッシュが使用されていない限り、それに送信されたコマンドグループの成功または失敗のみを決定します。

post-receive

このフックは git-receive-pack[1]git push に応答し、リポジトリ内の参照を更新するときに呼び出されます。提案されたすべての参照更新が処理された後、そして少なくとも1つの参照が結果として更新された場合に、リモートリポジトリで1回実行されます。

このフックは引数を受け取りません。pre-receive フックと同じ形式で、正常に更新された各参照について標準入力に1行を受け取ります。

このフックは、実際の作業が完了した後に呼び出されるため、git receive-pack の結果には影響しません。

これは post-update フックに取って代わるもので、参照の名前だけでなく、すべての参照の古い値と新しい値の両方を取得します。

標準出力と標準エラー出力の両方が、反対側の git send-pack に転送されるため、ユーザーにメッセージを echo するだけで済みます。

デフォルトの post-receive フックは空ですが、Git ディストリビューションの contrib/hooks ディレクトリには、コミットメールの送信を実装するサンプルスクリプト post-receive-email が提供されています。

git push --push-option=... のコマンドラインで指定されたプッシュオプションの数は、環境変数 GIT_PUSH_OPTION_COUNT から読み取ることができ、オプション自体は GIT_PUSH_OPTION_0GIT_PUSH_OPTION_1、…​ に見られます。プッシュオプションフェーズを使用しないようにネゴシエートされた場合、環境変数は設定されません。クライアントがプッシュオプションの使用を選択したが、何も送信しない場合、カウント変数はゼロ、GIT_PUSH_OPTION_COUNT=0 に設定されます。

追加の詳細については、git-receive-pack[1] の「post-receive」セクションを参照してください。

post-update

このフックは git-receive-pack[1]git push に応答し、リポジトリ内の参照を更新するときに呼び出されます。すべての参照が更新された後、リモートリポジトリで1回実行されます。

実際に更新された参照の名前である、可変個のパラメータを受け取ります。

このフックは主に通知を目的としており、git receive-pack の結果に影響を与えることはできません。

post-update フックはプッシュされたヘッドを知ることができますが、それらの元の値と更新された値を知らないため、old..new をログに記録するのに適した場所ではありません。post-receive フックは参照の元の値と更新された値の両方を取得します。これらが必要な場合は、代わりにそちらを検討してください。

有効になっている場合、デフォルトの post-update フックは git update-server-info を実行して、dumb transports (例: HTTP) で使用される情報を最新の状態に保ちます。HTTP 経由でアクセスできる Git リポジトリを公開している場合は、このフックを有効にする必要があります。

標準出力と標準エラー出力の両方が、反対側の git send-pack に転送されるため、ユーザーにメッセージを echo するだけで済みます。

reference-transaction

このフックは、参照更新を実行するすべてのGitコマンドによって呼び出されます。参照トランザクションが準備、コミット、または中止されるたびに実行されるため、複数回呼び出される場合があります。このフックはシンボリック参照更新もサポートしています。

このフックは正確に1つの引数を取ります。これは、与えられた参照トランザクションが現在置かれている状態です。

  • "prepared": すべての参照更新がトランザクションにキューに入れられ、参照がディスク上でロックされました。

  • "committed": 参照トランザクションがコミットされ、すべての参照がそれぞれの新しい値を持つようになりました。

  • "aborted": 参照トランザクションが中止され、変更は実行されず、ロックが解除されました。

トランザクションに追加された各参照更新について、フックは標準入力に次の形式の行を受け取ります。

<old-value> SP <new-value> SP <ref-name> LF

<old-value> は参照トランザクションに渡された古いオブジェクト名、<new-value> は参照に格納される新しいオブジェクト名、<ref-name> は参照の完全名です。現在の値に関係なく参照を強制的に更新する場合、または参照を新たに作成する場合、<old-value> はすべてゼロのオブジェクト名です。これらのケースを区別するには、git rev-parse を介して <ref-name> の現在の値を調べることができます。

シンボリック参照更新の場合、<old_value> および <new-value> フィールドはオブジェクトの代わりに参照を示すことができます。参照は ref: 接頭辞で示され、たとえば ref:<ref-target> のようになります。

フックの終了ステータスは、「prepared」状態以外の状態では無視されます。「prepared」状態では、非ゼロの終了ステータスはトランザクションを中止させます。その場合、フックは「aborted」状態で呼び出されません。

push-to-checkout

このフックは git-receive-pack[1]git push に応答し、リポジトリ内の参照を更新するとき、およびプッシュが現在チェックアウトされているブランチを更新しようとし、receive.denyCurrentBranch 設定変数が updateInstead に設定されている場合に呼び出されます。このようなプッシュは、リモートリポジトリの作業ツリーとインデックスが現在チェックアウトされているコミットと異なる場合、デフォルトで拒否されます。作業ツリーとインデックスの両方が現在のコミットと一致する場合、それらは新しくプッシュされたブランチの先端と一致するように更新されます。このフックは、デフォルトの動作をオーバーライドするために使用されます。

このフックは、現在のブランチの先端が更新されるコミットを受け取ります。非ゼロのステータスで終了してプッシュを拒否することができます (その場合、インデックスや作業ツリーを変更してはなりません)。または、作業ツリーとインデックスに必要な変更を加えて、現在のブランチの先端が新しいコミットに更新されたときに目的の状態にし、ゼロのステータスで終了することができます。

たとえば、フックは単に git read-tree -u -m HEAD "$1" を実行して、git push の逆方向で実行される git fetch をエミュレートできます。git read-tree -u -m の2ツリー形式は、本質的に git switch または git checkout と同じです。これは、ブランチ間の差分と干渉しないローカルの変更を作業ツリーに保持しながらブランチを切り替えます。

pre-auto-gc

このフックは git gc --auto (git-gc[1] を参照) によって呼び出されます。パラメータは受け取らず、このスクリプトが非ゼロのステータスで終了すると、git gc --auto は中止されます。

post-rewrite

このフックはコミットを書き換えるコマンドによって呼び出されます (git-commit[1]--amend オプションで呼び出された場合や git-rebase[1] など)。ただし、git-fast-import[1]git-filter-repo のような全履歴 (再) 書き換えツールは通常呼び出しません!最初の引数は、それが呼び出されたコマンドを示します。現在、amend または rebase のいずれかです。将来的に、コマンドに依存する追加の引数が渡される可能性があります。

このフックは、標準入力に書き換えられたコミットのリストを次の形式で受け取ります。

<old-object-name> SP <new-object-name> [ SP <extra-info> ] LF

extra-info は再びコマンドに依存します。それが空の場合、前の SP も省略されます。現在、どのコマンドも extra-info を渡しません。

フックは、自動ノートコピー ( git-config[1] の「notes.rewrite.<command>」を参照) が発生した後に常に実行されるため、これらのノートにアクセスできます。

以下のコマンド固有のコメントが適用されます。

rebase

squash および fixup 操作の場合、スカッシュされたすべてのコミットは、スカッシュされたコミットに書き換えられたものとしてリストされます。これは、同じ new-object-name を共有する複数の行があることを意味します。

コミットは、リベースによって処理された順序でリストされることが保証されています。

sendemail-validate

このフックは git-send-email[1] によって呼び出されます。

次のコマンドライン引数を受け取ります。1. 送信するメールの内容を保持するファイルの名前。2. メールSMTPヘッダーを保持するファイルの名前。

SMTP ヘッダーは、ユーザーのメール転送エージェント (MTA) に渡されるのとまったく同じ方法で渡されます。つまり、ユーザーの MTA に与えられるメールは、$2 の内容の後に $1 の内容が続きます。

いくつかの一般的なヘッダーの例を以下に示します。大文字小文字の区別と複数行のタブ構造に注意してください。

From: Example <from@example.com>
To: to@example.com
Cc: cc@example.com,
 A <author@example.com>,
 One <one@example.com>,
 two@example.com
Subject: PATCH-STRING

非ゼロのステータスで終了すると、メールが送信される前に git send-email は中止されます。

フックの実行時には以下の環境変数が設定されます。

GIT_SENDEMAIL_FILE_COUNTER

送信されるメールを保持するファイル (FIFO を除く) ごとに1ずつ増分される1ベースのカウンターです。このカウンターはパッチシリーズのカウンタースキームに従いません。常に1から始まり、GIT_SENDEMAIL_FILE_TOTAL で終わります。

GIT_SENDEMAIL_FILE_TOTAL

送信されるファイルの総数 (FIFO を除く) です。このカウンターはパッチシリーズのカウンタースキームに従いません。カバーレターがあるかどうかに関係なく、常に送信されるファイルの数と等しくなります。

これらの変数は、たとえばパッチシリーズの検証に使用できます。

Git に付属のサンプル sendemail-validate フックは、送信されたすべてのパッチ (カバーレターを除く) が、競合なく upstream リポジトリのデフォルトブランチに適用できることを確認します。特定のシリーズのすべてのパッチが適用された後に行われる追加の検証ステップのために、いくつかのプレースホルダーが残されています。

fsmonitor-watchman

このフックは、フックのバージョンに応じて、設定オプション core.fsmonitor.git/hooks/fsmonitor-watchman または .git/hooks/fsmonitor-watchmanv2 に設定されている場合に呼び出されます。

バージョン1は、バージョン (1) と、1970年1月1日真夜中からの経過ナノ秒の時間を2つの引数として取ります。

バージョン2は、バージョン (2) と、トークン以降の変更を識別するために使用されるトークンの2つの引数を取ります。watchman の場合、これはクロック ID になります。このバージョンは、ファイルリストの前に新しいトークンを NUL で区切って標準出力に出力する必要があります。

フックは、要求された時刻以降に変更された可能性のある作業ディレクトリ内のすべてのファイルのリストを標準出力に出力する必要があります。ロジックは包括的であるため、潜在的な変更を見逃してはなりません。パスは作業ディレクトリのルートに対する相対パスであり、単一の NUL で区切る必要があります。

実際に変更されていないファイルを含めても問題ありません。新しく作成されたファイルや削除されたファイルを含むすべての変更を含める必要があります。ファイルの名前が変更された場合、古い名前と新しい名前の両方を含める必要があります。

Gitは、パス名に基づいて、変更をチェックするファイルと、追跡されていないファイルをチェックするディレクトリを制限します。

「すべてのファイルが変更された」ことを Git に伝えるための最適化された方法は、ファイル名 / を返すことです。

終了ステータスは、Git がフックからのデータを使用して検索を制限するかどうかを決定します。エラーが発生した場合、すべてのファイルとフォルダを検証するようにフォールバックします。

p4-changelist

このフックは git-p4 submit によって呼び出されます。

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

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

詳細については git-p4 submit --help を実行してください。

p4-prepare-changelist

このフックは git-p4 submit によって呼び出されます。

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

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

詳細については git-p4 submit --help を実行してください。

p4-post-changelist

このフックは git-p4 submit によって呼び出されます。

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

詳細については git-p4 submit --help を実行してください。

p4-pre-submit

このフックは git-p4 submit によって呼び出されます。パラメータは受け取らず、標準入力からも何も受け取りません。このスクリプトが非ゼロのステータスで終了すると、git-p4 submit の起動が妨げられます。--no-verify コマンドラインオプションでバイパスできます。詳細については git-p4 submit --help を実行してください。

post-index-change

このフックは、index が read-cache.c do_write_locked_index で書き込まれるときに呼び出されます。

フックに渡される最初のパラメータは、作業ディレクトリが更新されたかどうかのインジケータです。「1」は作業ディレクトリが更新されたことを意味し、「0」は作業ディレクトリが更新されなかったことを意味します。

フックに渡される2番目のパラメータは、インデックスが更新されたかどうか、および skip-worktree ビットが変更されたかどうかを示すインジケータです。「1」は skip-worktree ビットが更新された可能性があることを意味し、「0」は更新されなかったことを意味します。

フックが実行されるとき、1つのパラメータのみを「1」に設定する必要があります。「1」、「1」を渡してフックを実行することはできません。

関連項目

GIT

git[1]スイートの一部

scroll-to-top