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

名前

git-notes - オブジェクトのノートを追加または検査する

概要

git notes [list [<object>]]
git notes add [-f] [--allow-empty] [--[no-]separator | --separator=<paragraph-break>] [--[no-]stripspace] [-F <file> | -m <msg> | (-c | -C) <object>] [-e] [<object>]
git notes copy [-f] ( --stdin | <from-object> [<to-object>] )
git notes append [--allow-empty] [--[no-]separator | --separator=<paragraph-break>] [--[no-]stripspace] [-F <file> | -m <msg> | (-c | -C) <object>] [-e] [<object>]
git notes edit [--allow-empty] [<object>] [--[no-]stripspace]
git notes show [<object>]
git notes merge [-v | -q] [-s <strategy> ] <notes-ref>
git notes merge --commit [-v | -q]
git notes merge --abort [-v | -q]
git notes remove [--ignore-missing] [--stdin] [<object>…​]
git notes prune [-n] [-v]
git notes get-ref

説明

オブジェクト自体に手を加えることなく、オブジェクトに添付されたノートを追加、削除、または読み取ります。

デフォルトでは、ノートは refs/notes/commits に保存され、そこから読み取られますが、このデフォルトは上書きできます。詳細については、以下の OPTIONS、CONFIGURATION、および ENVIRONMENT セクションを参照してください。このリファレンスが存在しない場合、ノートを保存するために最初に必要になったときに静かに作成されます。

ノートの典型的な使用方法は、コミット自体を変更せずにコミットメッセージを補足することです。ノートは git log で元のコミットメッセージとともに表示できます。これらのノートをコミットオブジェクトに保存されたメッセージと区別するために、ノートは「Notes (<refname>):」(または refs/notes/commits の場合は「Notes:」) と書かれたインデントなしの行の後に、メッセージのようにインデントされて表示されます。

ノートは、--notes オプションを使用して git format-patch で準備されたパッチにも追加できます。このようなノートは、3つのダッシュ区切り線の後にパッチコメントとして追加されます。

git log で表示されるノートを変更するには、CONFIGURATIONnotes.displayRef の説明を参照してください。

コミットを書き換えるコマンド間でノートを引き継ぐ方法については、notes.rewrite.<command> の設定を参照してください。

サブコマンド

list

指定されたオブジェクトのノートオブジェクトを一覧表示します。オブジェクトが指定されていない場合は、すべてのノートオブジェクトとそれらが注釈を付けているオブジェクトのリストを(「<note-object> <annotated-object>」の形式で)表示します。サブコマンドが指定されていない場合のデフォルトのサブコマンドです。

add

指定されたオブジェクト(デフォルトは HEAD)にノートを追加します。オブジェクトに既にノートがある場合は中止します(既存のノートを上書きするには -f を使用します)。ただし、add を対話的に(エディターを使用してノートの内容を提供して)使用している場合は、中止する代わりに、既存のノートがエディターで開かれます(edit サブコマンドのように)。複数の -m-F を指定すると、メッセージ間に空白行が挿入されます。他の区切り文字を挿入するには --separator オプションを使用します。ノートを追加する前に、-e を使用して、-m および -F オプションから提供されたメッセージを対話的に(エディターを使用して)編集し、微調整することができます。

copy

最初のオブジェクトのノートを2番目のオブジェクト(デフォルトは HEAD)にコピーします。2番目のオブジェクトに既にノートがある場合、または最初のオブジェクトにノートがない場合は中止します(2番目のオブジェクトの既存のノートを上書きするには -f を使用します)。このサブコマンドは次のコマンドと等価です: git notes add [-f] -C $(git notes list <from-object>) <to-object>

--stdin モードでは、標準入力から次の形式の行を受け取ります。

<from-object> SP <to-object> [ SP <rest> ] LF

<from-object> から対応する <to-object> にノートをコピーします。(オプションの <rest> は無視されるため、コマンドは post-rewrite フックに与えられた入力を読み取ることができます。)

--stdin は、コマンドラインで指定されたオブジェクト名と組み合わせることはできません。

append

オブジェクト(デフォルトは HEAD)に既存のノートがある場合は、-m または -F オプションで指定された新しいメッセージを既存のノートに追加するか、ノートが存在しない場合は新しいノートとして追加します。既存のノートに追加する場合、各新しいメッセージの前に空白行が段落間の区切り文字として追加されます。区切り文字は --separator オプションでカスタマイズできます。-m および -F オプションで指定された追加するノートを、ノートを追加する前に -e を使用して対話的に(エディターを使用して)編集します。

edit

指定されたオブジェクト(デフォルトは HEAD)のノートを編集します。

show

指定されたオブジェクト(デフォルトは HEAD)のノートを表示します。

merge

指定されたノートリファレンスを現在のノートリファレンスにマージします。これにより、マージベース(もしあれば)以降に指定されたノートリファレンス(「リモート」と呼びます)によって行われた変更を、現在のノートリファレンス(「ローカル」と呼びます)にマージしようとします。

競合が発生し、競合するノートを自動的に解決するための戦略(「NOTES MERGE STRATEGIES」セクションを参照)が指定されていない場合、manual リゾルバが使用されます。このリゾルバは、特別な作業ツリー(.git/NOTES_MERGE_WORKTREE)に競合するノートをチェックアウトし、ユーザーにそこで手動で競合を解決するように指示します。完了したら、ユーザーは git notes merge --commit でマージを完了するか、git notes merge --abort でマージを中止することができます。

remove

指定されたオブジェクト(デフォルトは HEAD)のノートを削除します。コマンドラインからゼロまたは1つのオブジェクトを指定した場合、これは edit サブコマンドに空のノートメッセージを指定するのと等価です。

--stdin モードでは、標準入力で指定されたオブジェクト名も削除します。つまり、--stdin はコマンドラインのオブジェクト名と組み合わせることができます。

prune

存在しない/到達不能なオブジェクトのすべてのノートを削除します。

get-ref

現在のノートリファレンスを出力します。これは、現在のノートリファレンスを(スクリプトなどから)簡単に取得する方法を提供します。

オプション

-f
--force

既にノートがあるオブジェクトにノートを追加する場合、既存のノートを上書きします(中止する代わりに)。

-m <msg>
--message=<msg>

指定されたノートメッセージを使用します(プロンプトを表示する代わりに)。複数の -m オプションが指定された場合、その値は別々の段落として連結されます。

-F <file>
--file=<file>

指定されたファイルからノートメッセージを取得します。標準入力からノートメッセージを読み取るには - を使用します。

-C <object>
--reuse-message=<object>

指定されたブロブオブジェクト(例: 別のノート)をノートメッセージとして使用します。(オブジェクト間でノートをコピーするには、代わりに git notes copy <object> を使用します。)デフォルトの動作はメッセージをそのままコピーすることであるため、--no-stripspace を含意します。

-c <object>
--reedit-message=<object>

-C と同様ですが、-c の場合はエディターが起動され、ユーザーがノートメッセージをさらに編集できます。

--allow-empty

空のノートオブジェクトの保存を許可します。デフォルトの動作は、空のノートを自動的に削除することです。

--separator=<paragraph-break>
--separator
--no-separator

段落間のカスタム区切り文字として使用する文字列を指定します(必要に応じて末尾に改行が追加されます)。--no-separator の場合、段落間に区切り文字は追加されません。デフォルトは空白行です。

--stripspace
--no-stripspace

空白文字をクリーンアップします。具体的には(git-stripspace[1] を参照)

  • すべての行の末尾の空白を削除する

  • 複数の連続する空行を1つの空行にまとめる

  • 入力の最初と最後の空行を削除する

  • 必要に応じて、最終行に欠落している \n を追加する。

--stripspace-C/--reuse-message を除くデフォルトです。ただし、これは類似オプションの順序に依存することに注意してください。たとえば、-C <object> -m<message> の場合、-m のデフォルトが以前の -C を上書きするため、--stripspace が使用されます。これは既知の制限であり、将来修正される可能性があります。

--ref=<ref>

<ref> のノートツリーを操作します。これは GIT_NOTES_REF および core.notesRef の設定を上書きします。リファレンスが refs/notes/ で始まる場合は完全なリファレンス名、notes/ で始まる場合は refs/、それ以外の場合は refs/notes/ が接頭辞として付加されて完全なリファレンス名が形成されます。

--ignore-missing

ノートが添付されていないオブジェクトからノートを削除する要求をエラーと見なしません。

--stdin

removecopy のみに有効です。それぞれのサブコマンドを参照してください。

-n
--dry-run

何も削除しません。ノートが削除されるオブジェクト名のみを報告します。

-s <strategy>
--strategy=<strategy>

ノートをマージする際に、指定された戦略を使用してノートの競合を解決します。以下の戦略が認識されます: manual (デフォルト)、ourstheirsunion、および cat_sort_uniq。このオプションは notes.mergeStrategy の設定を上書きします。各ノートマージ戦略の詳細については、以下の「NOTES MERGE STRATEGIES」セクションを参照してください。

--commit

進行中の git notes merge を完了します。git notes merge.git/NOTES_MERGE_WORKTREE に保存した競合を解決した場合にこのオプションを使用します。これは、git notes merge によって作成された部分的なマージコミット(.git/NOTES_MERGE_PARTIAL に保存されています)を、.git/NOTES_MERGE_WORKTREE のノートを追加して修正します。.git/NOTES_MERGE_REF シンボリックリファレンスに保存されているノートリファレンスは、結果のコミットに更新されます。

--abort

進行中の git notes merge、つまり競合のあるノートマージを中止/リセットします。これは、ノートマージに関連するすべてのファイルを単に削除します。

-q
--quiet

ノートをマージする際に、静かに操作します。

-v
--verbose

ノートをマージする際に、より詳細に表示します。ノートを削除する際に、ノートが削除されるすべてのオブジェクト名を報告します。

考察

コミットノートは、オブジェクトに関する追加情報(通常はコミットメッセージを補足する情報)を含むブロブです。これらのブロブはノート参照から取得されます。ノート参照は通常、パフォーマンス上の理由からディレクトリセパレータを含む、記述するオブジェクトのオブジェクト名がパスとなる「ファイル」を含むブランチです[1]

すべてのノート変更は、指定されたノート参照に新しいコミットを作成します。したがって、例えば git log -p notes/commits を呼び出すことで、ノートの履歴を検査できます。現在、コミットメッセージは更新をトリガーした操作のみを記録し、コミットの作成者は通常の規則に従って決定されます(git-commit[1] を参照)。これらの詳細は将来変更される可能性があります。

ノート参照が直接ツリーオブジェクトを指すことも許可されており、その場合、ノートの履歴は git log -p -g <refname> で読み取ることができます。

ノートマージ戦略

デフォルトのノートマージ戦略は manual です。これは、ノートの競合解決のために特別な作業ツリー(.git/NOTES_MERGE_WORKTREE)に競合するノートをチェックアウトし、ユーザーにその作業ツリーで競合を解決するように指示します。完了したら、ユーザーは git notes merge --commit でマージを完了するか、git notes merge --abort でマージを中止することができます。

ユーザーは、-s/--strategy オプションを使用するか、notes.mergeStrategy を適切に設定することにより、以下の自動マージ戦略の中から選択できます。

ours は、ローカルバージョン(つまり、現在のノート参照)を優先して競合するノートを自動的に解決します。

theirs は、リモートバージョン(つまり、現在のノート参照にマージされる指定されたノート参照)を優先してノートの競合を自動的に解決します。

union は、ローカルバージョンとリモートバージョンを連結することでノートの競合を自動的に解決します。

cat_sort_uniqunion に似ていますが、ローカルバージョンとリモートバージョンを連結するだけでなく、結果の行をソートし、重複する行を結果から削除します。これは、ローカルバージョンとリモートバージョンに「cat | sort | uniq」シェルパイプラインを適用するのと等価です。この戦略は、マージ結果で重複する行を避けたい行ベースの形式のノートに役立ちます。ローカルバージョンまたはリモートバージョンのいずれかがマージ前に重複する行を含んでいた場合、これらもこのノートマージ戦略によって削除されることに注意してください。

ノートを使用して、コミットが作成された時点では利用できなかった情報で注釈を追加できます。

$ git notes add -m 'Tested-by: Johannes Sixt <j6t@kdbg.org>' 72a144e2
$ git show -s 72a144e
[...]
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

Notes:
    Tested-by: Johannes Sixt <j6t@kdbg.org>

原則として、ノートは通常のGitブロブであり、あらゆる種類の(非)形式が受け入れられます。git hash-object を使用して、任意のファイルからバイナリセーフなノートを作成できます。

$ cc *.c
$ blob=$(git hash-object -w a.out)
$ git notes --ref=built add --allow-empty -C "$blob" HEAD

git notes --ref=built add -F a.out HEAD を単純に使うことはできません。それはバイナリセーフではないからです。)もちろん、git log でテキスト以外の形式のノートを表示することはあまり意味がないので、そのようなノートを使用する場合は、それらを有効に活用するために特殊なツールを作成する必要があるでしょう。

設定

core.notesRef

refs/notes/commits の代わりに読み書きするノート参照。省略されていない参照名である必要があります。この設定は、環境およびコマンドラインで上書きできます。

このセクションのこの行より上のすべての内容は、git-config[1] ドキュメントには含まれていません。以下の内容は、そちらにあるものと同じです。

notes.mergeStrategy

ノートの競合を解決する際に、デフォルトで選択するマージ戦略。 manualourstheirsunion、または cat_sort_uniq のいずれかである必要があります。デフォルトは manual です。各戦略の詳細については、git-notes[1] の「NOTES MERGE STRATEGIES」セクションを参照してください。

この設定は、git-notes[1]--strategy オプションを渡すことで上書きできます。

notes.<name>.mergeStrategy

refs/notes/<name> へのノートマージを実行する際に選択するマージ戦略。これはより一般的な notes.mergeStrategy を上書きします。利用可能な戦略の詳細については、git-notes[1] の「NOTES MERGE STRATEGIES」セクションを参照してください。

notes.displayRef

git log ファミリのコマンドでコミットメッセージを表示する際に、core.notesRef または GIT_NOTES_REF によって設定されたデフォルトのセットに加えて、どのリファレンス(または、globまたは複数回指定された場合は複数のリファレンス)からノートを読み取るか。

この設定は、環境変数 GIT_NOTES_DISPLAY_REF で上書きできます。これはコロン区切りのリファレンスまたはグロブのリストである必要があります。

存在しないリファレンスに対しては警告が発行されますが、どのリファレンスとも一致しないグロブは silently 無視されます。

この設定は、git-log[1] ファミリのコマンドの --no-notes オプション、またはこれらのコマンドで受け入れられる --notes=<ref> オプションによって無効にすることができます。

core.notesRef の実効値(GIT_NOTES_REF によって上書きされる場合があります)も、表示される参照のリストに暗黙的に追加されます。

notes.rewrite.<command>

<command>(現在のところ amend または rebase)でコミットを書き換える際に、この変数が false の場合、git は元のコミットから書き換えられたコミットへノートをコピーしません。デフォルトは true です。以下の notes.rewriteRef も参照してください。

この設定は環境変数 GIT_NOTES_REWRITE_REF で上書きできます。これはコロン区切りのリファレンスまたはグロブのリストである必要があります。

notes.rewriteMode

リライト中にノートをコピーする際(notes.rewrite.<command> オプションを参照)、ターゲットコミットにすでにノートがある場合の動作を決定します。overwriteconcatenatecat_sort_uniq、または ignore のいずれかである必要があります。デフォルトは concatenate です。

この設定は、環境変数 GIT_NOTES_REWRITE_MODE で上書きできます。

notes.rewriteRef

リライト中にノートをコピーする際、どの(完全修飾された)リファレンスのノートをコピーするかを指定します。グロブにすることも可能で、その場合、一致するすべてのリファレンスのノートがコピーされます。この設定を複数回指定することもできます。

デフォルト値はありません。ノートの書き換えを有効にするには、この変数を設定する必要があります。refs/notes/commits に設定すると、デフォルトのコミットノートの書き換えが有効になります。

環境変数 GIT_NOTES_REWRITE_REF で上書きできます。その形式の詳細については、上記の notes.rewrite.<command> を参照してください。

環境変数

GIT_NOTES_REF

refs/notes/commits の代わりにノートを操作するリファレンス。これは core.notesRef の設定を上書きします。

GIT_NOTES_DISPLAY_REF

コミットメッセージを表示する際に、core.notesRef または GIT_NOTES_REF からのデフォルトに加えて、どのリファレンスからノートを読み取るかを示すコロン区切りのリファレンスまたはグロブのリスト。これは notes.displayRef の設定を上書きします。

存在しないリファレンスに対しては警告が発行されますが、どのリファレンスとも一致しないグロブは silently 無視されます。

GIT_NOTES_REWRITE_MODE

リライト中にノートをコピーする際、ターゲットコミットに既にノートがある場合の動作。overwriteconcatenatecat_sort_uniq、または ignore のいずれかである必要があります。これは core.rewriteMode の設定を上書きします。

GIT_NOTES_REWRITE_REF

コミットを書き換える際に、元のコミットから書き換えられたコミットにコピーするノート。コロン区切りのリファレンスまたはグロブのリストである必要があります。

環境変数で設定されていない場合、コピーするノートのリストは notes.rewrite.<command> および notes.rewriteRef の設定に依存します。

GIT

git[1]スイートの一部


1. 許可されるパス名は bf/fe/30/…​/680d5a…​ の形式です。これは、それぞれ2桁の16進数で構成されるディレクトリ名のシーケンスに、オブジェクトIDの残りの部分がファイル名として続きます。
scroll-to-top