git-rev-parse(1)

SYNOPSIS

git rev-parse [<options>] <args>…

DESCRIPTION

多くのGit磁器コマンドは、内部で使用されベースとなる git rev-list コマンド用のフラグとパラメーターの組み合わせと、 git rev-list の下流で使用する他のコマンドのフラグとパラメーターの組み合わせを使用します。このコマンドは、それらを識別するために使用されます。

OPTIONS

Operation Modes

これらの各オプションは、コマンドラインの最初にある必要があります。

--parseopt: オプション解析モードで git rev-parse を使用します(以下の PARSEOPT セクションを参照)。
--sq-quote: シェルクォートモードで git rev-parse を使用します(以下の SQ-QUOTE セクションを参照)。以下の --sq オプションとは対照的に、このモードはクォートのみを実行します。コマンド入力に対して他に何も行われません。

Options for `--parseopt`

--keep-dashdash: --parseopt モードでのみ意味があります。オプションパーサーに、最初に出会った -- をスキップするのではなく、エコー出力(echo out)するように指示します。
--stop-at-non-option: --parseopt モードでのみ意味があります。オプションパーサーを最初の非オプション引数で停止させます。これは、オプション自体を受け取るサブコマンドを解析するために使用できます。
--stuck-long: --parseopt モードでのみ意味があります。可能な場合は長い形式でオプションを出力し、それらの引数を固定(stick)します。

Options for Filtering

--revs-only: git rev-list コマンド用ではないフラグやパラメーターを出力しないでください。
--no-revs: git rev-list コマンド用のフラグとパラメーターを出力しないでください。
--flags: 非フラグパラメータを出力しないでください。
--no-flags: フラグパラメータを出力しないでください。

Options for Output

--default <arg>

ユーザーが指定したパラメーターがない場合は、代わりに <arg> を使用してください。

--prefix <arg>

git rev-parse が作業ツリーの <arg> サブディレクトリから呼び出されたかのように動作します。相対ファイル名は、接頭辞が <arg> であるかのように解決され、その形式で出力されます。

これを使用して、引数をサブディレクトリで実行されるコマンドに変換し、リポジトリの最上位に移動した後も使用できるようにすることができます。例えば:

prefix=$(git rev-parse --show-prefix)
cd "$(git rev-parse --show-toplevel)"
# rev-parse provides the -- needed for 'set'
eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")"

--verify

正確に1つのパラメーターが提供されていること、およびそれがオブジェクト・データベースへのアクセスに使用できる生の20バイトのSHA-1に変換できることを検証します。もしそうなら、それを標準出力に出力します。それ以外の場合は、エラー出力になります。

出力が実際にオブジェクトデータベース内のオブジェクトに名前を付けていること、および/または必要な特定のタイプのオブジェクトとして使用できることを確認したい場合は、パラメータに ^{type} 皮むき演算子(peeling operator)を追加できます。たとえば、 git rev-parse "$VAR^{commit}" は、 $VAR がコミットっぽい既存のオブジェクト(つまりコミット、またはコミットを指す注釈付きタグ)に名前を付けることを確認します。 $VAR が任意のタイプの既存のオブジェクトに名前を付けるようにするには、 git rev-parse "$VAR^{object}" を使用できます。

注意: 信頼できないソースからの名前を検証(verify)する場合は、name引数が別のオプションと間違えられないように、 --end-of-options の使用が賢明です。

-q

--quiet

--verify モードでのみ意味があります。最初の引数が有効なオブジェクト名でない場合は、エラーメッセージを出力しないでください。代わりに、ゼロ以外のステータスで黙って終了(exit)します。有効なオブジェクト名のSHA-1は、成功するとstdoutに出力されます。

--sq

通常、出力はフラグとパラメータごとに1行になります。このオプションは、シェルによって消費されるための適切に引用された1行の出力を作成します。パラメータに空白と改行が含まれていると予想される場合に便利です(たとえば、 pickaxe -S with git diff-* )。 --sq-quote オプションとは対照的に、コマンド入力は通常どおり解釈されます。

--short[=length]

--verify と同じですが、オブジェクト名を少なくとも length 文字の一意のプレフィックスに短縮します。最小の長さは4で、デフォルトは core.abbrev 構成変数の有効な値です(git-config(1)を参照)。

--not

オブジェクト名を表示するときは、それらに {caret} というプレフィックスを付け、逆に既に、 {caret} プレフィックスを持っているオブジェクト名からは {caret} プレフィックスを削除します。

--abbrev-ref[=(strict|loose)]

オブジェクト名のあいまいでない短い名前。オプション core.warnAmbiguousRefs は、厳密な省略形モードを選択するために使用されます。

--symbolic

通常、オブジェクト名はSHA-1形式で出力されます(可能な場合は {caret} プレフィックス付き)。このオプションを使用すると、入力されたオリジナルにできるだけ近い形式で出力されます。

--symbolic-full-name

これは --symbolic に似ていますが、ref(つまり、ブランチ名とタグ名。または、残念ながら master と名付けられたタグがあるとき master ブランチに名前を付けたい場合はより明確な heads/master 形式である)ではない入力を省略し、完全なrefname(例: "refs/heads/master")として表示します。

Options for Objects

--all: refs/ で見つかったすべての参照を表示します。
--branches[=pattern]
--tags[=pattern]
--remotes[=pattern]: すべてのブランチまたはタグまたはリモートトラッキングブランチをそれぞれ表示します(つまり、それぞれ refs/heads または refs/tags または refs/remotes で見つかったref)。

pattern が指定されている場合、指定されたシェルグロブに一致するrefのみが表示されます。パターンにグロビング文字(? または * または [)が含まれていない場合は、 /* を追加することでプレフィックス一致に変換されます。
--glob=pattern: シェルグロブパターン pattern に一致するすべてのrefを表示します。パターンが refs/ で始まらない場合、自動的に先頭に追加されます。パターンにグロビング文字(? または * または [)が含まれていない場合は、 /* を追加することでプレフィックス一致に変換されます。
--exclude=<glob-pattern>: このオプションに続く --all または --branches または --tags または --remotes または --glob がそれぞれ考慮する <glob-pattern> に一致するrefを含めないでください。このオプションを繰り返すと、次の --all または --branches または --tags または --remotes または --glob オプションまで除外パターンが蓄積されます(他のオプションや引数は蓄積されたパターンをクリアしませんされません)。

与えられたパターンは、それぞれ --branches または --tags または --remotes に適用される場合、それぞれ refs/heads 、 refs/tags 、refs/remotes で始まるべきではありません。 --glob または --all に適用する場合は、 refs/ で始める必要があります。末尾の /* を意図している場合は、それを明示的に指定する必要があります。
--disambiguate=<prefix>: 名前が、指定されたプレフィックスで始まるすべてのオブジェクトを表示します。 <prefix> は、リポジトリ内のすべてのオブジェクトを誤ってリストしないように、少なくとも4桁の16進数である必要があります。

Options for Files

--local-env-vars: リポジトリローカルな GIT_* 環境変数を一覧表示します(例: GIT_DIRまたはGIT_WORK_TREE、ただしGIT_EDITORは除く)。変数が設定されている場合でも、変数の名前のみがリストされ、値はリストされません。
--path-format=(absolute|relative): 他の特定のオプションの動作を制御します。absolute(絶対)を指定すると、これらのオプションによって出力されるパスは絶対パスかつ正規化されます。relative(相対)を指定すると、可能であれば、パスは現在の作業ディレクトリからの相対パスになります。デフォルトは対象の、他の特定のオプションそれぞれ固有です。

このオプションは複数回指定でき、コマンドラインの最後か、またはこのオプションの次のインスタンスかの、いずれかに続くコマンドラインの引数にのみ影響します。

以下のオプションは --path-format による変更対象です:

--git-dir: 定義されている場合は $GIT_DIR を表示します。それ以外の場合は、 .git ディレクトリへのパスを表示します。表示されているパスは、相対の場合、現在の作業ディレクトリからの相対パスです。

$GIT_DIR が定義されておらず、現在のディレクトリがGitリポジトリまたは作業ツリーにあることが検出されない場合は、標準エラー出力にメッセージを出力し、ゼロ以外のステータスで終了(exit)します。
--git-common-dir: 定義されている場合は $GIT_COMMON_DIR を表示し、そうでない場合は $GIT_DIR を表示します。
--resolve-git-dir <path>: <path> が有効なリポジトリまたは有効なリポジトリを指す gitfile であるかどうかを確認し、リポジトリの場所を出力します。 <path> が gitfile の場合、実際のリポジトリへの解決されたパス(resoluved path)が出力されます。
--git-path <path>: $GIT_DIR/<path> を解決し、 $GIT_OBJECT_DIRECTORY、$GIT_INDEX_FILE…などの他のパス再配置変数を考慮に入れます。たとえば、 $GIT_OBJECT_DIRECTORY が /foo/bar に設定されている場合、 git rev-parse --git-path objects/abc は /foo/bar/abc を返します。
--show-toplevel: 作業ツリーの最上位ディレクトリの(デフォルトでは絶対)パスを表示します。作業ツリーがない場合は、エラーを報告します。
--show-superproject-working-tree: 現在のリポジトリをサブモジュールとして使用するスーパープロジェクトの作業ツリー(存在する場合)のルート(root)の絶対パスを表示します。現在のリポジトリがどのプロジェクトでもサブモジュールとして使用されていない場合は、何も出力しません。
--shared-index-path: 共有インデックスファイル(shared index file)へのパスを分割インデックスモード(split index mode)で表示します。分割インデックスモードで無い場合は空です。

以下のオプションは、 --path-format の影響を受けません:

--absolute-git-dir: --git-dir に似ていますが、その出力は常に正規化された絶対パスです。
--is-inside-git-dir: 現在の作業ディレクトリがリポジトリディレクトリ(訳注: 通常 .git ディレクトリ)の下にある場合は true 、それ以外の場合は false と出力します。
--is-inside-work-tree: 現在の作業ディレクトリがリポジトリの作業ツリー内にある場合は true 、それ以外の場合は false と出力します。(訳注 .git ディレクトリ内では false)
--is-bare-repository: ベアリポジトリの場合は true 、それ以外の場合は false を出力。
--is-shallow-repository: shallowリポジトリの場合は true 、そうでない場合は false を出力します。
--show-cdup: コマンドがサブディレクトリから呼び出された場合は、現在のディレクトリを基準にした最上位ディレクトリのパスを表示します(通常は ../ のシーケンスまたは空の文字列)。(訳注:作業ディレクトリ内じゃない時はエラー)
--show-prefix: コマンドがサブディレクトリから呼び出された場合は、最上位ディレクトリを基準にした現在のディレクトリのパスを表示します。(訳注:作業ディレクトリ内じゃない時はエラー)
--show-object-format[=(storage|input|output)]: .git ディレクトリ内でリポジトリのために使われるストレージ(storage)、または入力(input)、または出力(output)に使われるオブジェクト形式(ハッシュアルゴリズム)を表示します。入力(input)の場合、複数のアルゴリズムがスペースで区切られて出力される場合があります。形式を指定しない場合、デフォルトは storage です。

Other Options

--since=datestring
--after=datestring: 日付文字列をパースし、 git rev-list に対応する -max-age= パラメーターを出力します。
--until=datestring
--before=datestring: 日付文字列をパースし、 git rev-list に対応する --min-age= パラメーターを出力します。
<args>…: パースされるフラグとパラメーター。

SPECIFYING REVISIONS

リビジョンパラメータ <rev> は必ずしもそうとは限りませんが、通常はコミットオブジェクトに名前を付けます。これは、いわゆる「拡張SHA-1」構文を使用します。オブジェクト名を綴るにはさまざまな方法があります。このリストの終わり近くにリストされているものは、コミットに含まれているツリーとブロブに名前を付けています。

Note	この文書は、gitで見られる「生の」構文を示しています。シェルおよびその他のUIでは、特殊文字を保護し、単語の分割を回避するために、追加の引用符が必要になる場合があります。

<sha1> 例: dae86e1950b1277e545cee180551750029cfe735, dae86e

完全なSHA-1オブジェクト名(40バイトの16進文字列)、またはリポジトリ内で一意の先頭のsubstring。例えば dae86e1950b1277e545cee180551750029cfe735 と dae86e はどちらも、リポジトリ内にオブジェクト名が dae86e で始まる他のオブジェクトがない場合、全く同じコミットオブジェクトに名前を付けます。

<describeOutput> 例: v1.7.4.2-679-g3bee7fb

git describe からの出力。つまり、現在のコミットから最も近いタグ。オプションで、ダッシュ(-)とそのタグ以降現在のコミットが何番目になるかの数が続き、その後にダッシュ(-)、「g」、および省略されたオブジェクト名が続きます。

<refname> 例: master, heads/master, refs/heads/master

シンボリックref名。例えば master は通常、 refs/heads/master によって参照されるコミットオブジェクトを意味します。 heads/master と tags/master の両方がある場合は、あなたは heads/master と明示的に指定して、どちらを意味するかをGitに伝えることができます。あいまいな場合、 <refname> は、以下のルールに従い最初の一致を採用ことで明確になります:

もし $GIT_DIR/<refname> が存在するならば、それはあなたが指定した通りのものです(これは通常、HEAD と FETCH_HEAD と ORIG_HEAD と MERGE_HEAD と CHERRY_PICK_HEAD のみで役に立ちます)
でなければ refs/<refname> が存在すればそれを採用します。
でなければ refs/tags/<refname> が存在すればそれを採用します。
でなければ refs/heads/<refname> が存在すればそれを採用します。
でなければ refs/remotes/<refname> が存在すればそれを採用します。
でなければ refs/remotes/<refname>/HEAD が存在すればそれを採用します。

HEAD は、作業ツリーの変更に基づいたコミットに名前を付けます。 FETCH_HEAD は、最後の git fetch 呼び出しでリモートリポジトリからフェッチしたブランチを記録します。 ORIG_HEAD は、 HEAD を大幅に移動するコマンドによって作成され、操作前の HEAD の位置を記録します。これにより、ブランチの先端を実行前の状態に簡単に戻すことができます。 MERGE_HEAD は、 git merge を実行するときにブランチにマージするコミットを記録します。 CHERRY_PICK_HEAD は、 git cherry-pick を実行したときにチェリーピックしているコミットを記録します。

注意: 上記の refs/* の場合、 $GIT_DIR/refs ディレクトリまたは $GIT_DIR/packed-refs ファイルのいずれかから発生する可能性があることに注意してください。ref名のエンコードは指定されていませんが、一部の出力処理ではUTF-8でref名を想定する場合があるため、UTF-8が推奨されます。

@

@ 単独では HEAD のショートカットを意味します。

[<refname>]@{<date>} 例: master@{yesterday}, HEAD@{5 minutes ago}

refの後に接尾辞 @ が続き、日付指定が中括弧のペアで囲まれています(例: {yesterday} 、 {1 month 2 weeks 3 days 1 hour 1 second ago} 、{1979-02-26 18:30:00} )。これは以前の時点でのrefの値を指定します。この接尾辞は、ref名の直後にのみ使用でき、refには既存のログ( $GIT_DIR/logs/<ref> )が必要です。これは、特定の時点での ローカル refの状態を検索することに注意してください。たとえば、先週ローカルの master ブランチに何があったか、です。特定の時間に行われたコミットを確認する場合は、 --since と --until を参照してください。

<refname>@{<n>} 例: master@{1}

refの後に接尾辞 @ が続き、数の指定が中括弧のペアで囲まれている場合(たとえば {1}, {15})、そのrefのn個前の値を指定します。たとえば master@{1} は master の直前の値であり、 master@{5} は master の5個前の値です。この接頭辞は、ref名の直後にのみ使用でき、refには既存のログ( $GIT_DIR/logs/<refname> )が必要です。

@{<n>} 例: @{1}

空のref部分で @ コンストラクトを使用して、現在のブランチのreflogエントリを取得できます。たとえば、あなたがブランチ blabla を使用している場合、 @{1} は blabla@{1} と同じ意味になります。

@{-<n>} 例: @{-1}

構成 @{-<n>} は、現在のブランチ/コミットの前にチェックアウトされた<n>番目のブランチ/コミットを意味します。

[<branchname>]@{upstream} 例: master@{upstream}, @{u}

ブランチ B は、リモート R (branch.<name>.remote で構成)で、ブランチ X (branch.<name>.merge で構成)の上に構築するようにセットアップできます。 B@{u} は、リモート R から取られたブランチ X のリモート追跡ブランチを参照し、通常は refs/remotes/R/X にあります。

[<branchname>]@{push} 例: master@{push}, @{push}

接尾辞 @\{push} は、 branchname がチェックアウトされているときに git push が実行された場合(またはブランチ名が指定されていない場合は現在の HEAD )、「プッシュ先」のブランチを報告します。 @\{upstream\} の場合と同様に、リモートのブランチに対応するリモート・トラッキング・ブランチを報告します。

ここで、よりはっきり分かる例を以下に示します:

$ git config push.default current
$ git config remote.pushdefault myfork
$ git switch -c mybranch origin/master

$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/master

$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch

注意: この例では、ある場所からプルして別の場所にプッシュする三角形のワークフローを設定していることに注意してください。非三角形のワークフローでは、 @\{push} は @\{upstream} と同じであり、このようなことをする必要はありません。

この接尾辞は大文字で綴る場合にも受け入れられ、大文字と小文字を問わず同じことを意味します。

<rev>^[<n>] 例: HEAD^, v1.5.1^0

リビジョンパラメータの接尾辞 ^ は、そのコミットオブジェクトの最初の親を意味します。 ^<n> は <n> 番目の親を意味します(つまり、 <rev>^ は <rev>^1 と同じです)。特別ルールとして、 <rev>^0 はコミット自体を意味し、 <rev> がコミットオブジェクトを参照するタグオブジェクトのオブジェクト名である場合に使用されます。

<rev>~[<n>] 例: HEAD~, master~3

リビジョンパラメータの接尾辞 ~ は、そのコミットオブジェクトの最初の親を意味します。リビジョンパラメータの接尾辞 ~<n> は、最初の親のみに続く、指定されたコミットオブジェクトの <n> 世代の祖先であるコミットオブジェクトを意味します。つまり、 <rev>~3 は <rev>^^^ と同じで、するってぇと <rev>^1^1^1 と同じということです。この形式については以下の図を参照してください。

<rev>^{<type>} 例: v0.99.8^{commit}

接尾辞 ^ の後に中括弧のペアで囲まれたオブジェクトタイプ名が続くということは、タイプ <type> のオブジェクトが見つかるか、オブジェクトを逆参照できなくなるまで、 <rev> でオブジェクトを再帰的に逆参照する(この場合は、いろいろ一旦飲み込んでしまったのを吐きもどすような感じだぬ)ことを意味します。たとえば、 <rev> がコミットっぽい場合、 <rev>^{commit} は対応するコミットオブジェクトを記述します。同様に、 <rev> がツリーっぽい場合、 <rev>^{tree} は対応するツリーオブジェクトを記述します。 <rev>^0 は <rev>^{commit} の省略形です。

<rev>^{object} を使用すると、 <rev> がタグである必要がなく、 <rev> を逆参照することなく、 <rev> が存在するオブジェクトに名前を付けることができます。なお、タグはすでにオブジェクトであるため、オブジェクトに到達するために一度も逆参照する必要はありません。

<rev>^{tag} を使用して、 <rev> が既存のタグオブジェクトを確実に識別することができます。

<rev>^{} 例: v0.99.8^{}

接尾辞 ^ の後に空のブレースペアが続くということは、オブジェクトがタグである可能性があることを意味し、タグ以外のオブジェクトが見つかるまでタグを再帰的に逆参照します。

<rev>^{/<text>} 例: HEAD^{/fix nasty bug}

リビジョンパラメータの接尾辞 ^ と、それに続くスラッシュで始まるテキストを含む中括弧のペアは、以下の :/fix nasty bug 構文と同じですが、 ^ の前の <rev> から到達可能な一致する最も若いコミットを返す点が異なります。

:/<text> 例: :/fix nasty bug

コロンに続いてスラッシュそしてそれに続くテキストは、コミットメッセージが指定された正規表現と一致するコミットを示します。この名前は、HEADを含む任意のrefから到達可能な最も若い一致するコミットを返します。正規表現は、コミットメッセージの任意の部分に一致できます。文字列で始まるメッセージを照合するには、たとえば、 :/^foo とします。特別なシーケンス :/! はマッチングの修飾子用に予約されています。ます。 :/!-foo は一致の否定を実行し、 :/!!foo はリテラル ! 後に foo が続く文字列とマッチします。 :/! で始まるその他のシーケンスは今のところ予約されています。指定されたテキストによっては、シェルにより追加の引用符が必要になる場合があります。

<rev>:<path> 例: HEAD:README, master:./README

接尾辞 : の後にパス(path)を続けると、コロンの前の部分によって名前が付けられたツリー風のオブジェクト内の、指定されたパスにあるブロブまたはツリーに名前が付けられます。 ./ または ../ で始まるパスは、現在の作業ディレクトリからの相対パスです。指定のパスは、作業ツリーのルートディレクトリからの相対パスに変換されます。これは、作業ツリーと同じツリー構造を持つコミットまたはツリーからブロブまたはツリーをアドレス指定するのに最も役立ちます。

:[<n>:]<path> 例: :0:README, :README

コロンに、オプションでステージ番号(0〜3)とコロンが続き、それにパスが続くと、指定されたパスのインデックス内のブロブオブジェクトに名前を付けます。ステージ番号省略(およびそれに続くコロン)は、ステージ0エントリーを示します。マージ作業中、ステージ1は共通の祖先、ステージ2はターゲットブランチのバージョン(通常は現在のブランチ)、ステージ3はマージされるブランチのバージョンです。

以下はJon Loeligerによる図解です。コミットノードBとCはどちらもコミットノードAの親です。親コミットは左から右に順序付けられます。

G   H   I   J
 \ /     \ /
  D   E   F
   \  |  / \
    \ | /   |
     \|/    |
      B     C
       \   /
        \ /
         A

A =      = A^0
B = A^   = A^1     = A~1
C =      = A^2
D = A^^  = A^1^1   = A~2
E = B^2  = A^^2
F = B^3  = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2  = B^^2    = A^^^2  = A~2^2
I = F^   = B^3^    = A^^3^
J = F^2  = B^3^2   = A^^3^2

SPECIFYING RANGES

git log などの履歴トラバースコマンドは、単一のコミットだけでなく、一連のコミットで動作します。

これらのコマンドの場合、前のセクションで説明した表記法を使用して単一のリビジョンを指定することは、指定のコミットから「到達可能」なコミットの組を意味します。

複数のリビジョンを指定するということは、指定のコミットのいずれかから到達可能なコミットの組を意味します。

コミットの到達可能な組は、コミット自体とその祖先チェーン内のコミットです。

以下に示すように、接続されたコミット(connected commits)の組(「リビジョン範囲」(revision range)と呼ばれる)を指定するためのいくつかの表記法があります。

Commit Exclusions

^<rev> (カレット)記法: とある到達可能なコミットをコミット達から除外するには、接頭辞 ^ 表記を使用します。例えば ^r1 r2 は r2 から到達可能なコミットだけども、 r1 から到達可能なコミット(つまり r1 とその祖先)は除外する事を意味します。

Dotted Range Notations

.. (2ドット)範囲記法: ^r1 r2 操作は頻繁に表示されるため、省略形があります。(上記の SPECIFYING REVISIONS で説明されている構文に従って名前が付けられている)2つのコミット r1 と r2 がある場合、あなたは ^r1 r2 によってr1から到達可能なコミットを取り除き、r2から到達可能なコミットを要求できます。そしてこれは r1..r2 と書くことができます。
... (3ドット)対称差記法: 似た表記 r1...r2 は r1 と r2 の対称差と呼ばれ、 r1 r2 --not $(git merge-base --all r1 r2) として定義されます。これは、 r1 (左側)または r2 (右側)のいずれかから到達可能であるが、両方からは到達できないコミットの組です。

これらの2つの省略表記では、一方の端を省略して、デフォルトでHEADにすることができます。たとえば、 origin.. は origin..HEAD の省略形であり、「originブランチから分岐(fork)してから何をしましたか？」と尋ねます。同様に、 ..origin は HEAD..origin の省略形であり、「私がそれらから分岐してから、originは何をしましたか？」と尋ねます。 .. は HEAD..HEAD を意味することに注意してください。これは、HEADから到達可能および到達不能の両方の空の範囲です。

2つの異なる範囲を取るように特別に設計されたコマンド(たとえば、2つの範囲を比較するための "git range-diff R1 R2" ) は存在しますが、それらは例外です。特に明記されていない限り、一連のコミットを操作するすべての "git" コマンドは、単一のリビジョン範囲で機能します。言い換えると、2つの「2ドット範囲表記」を隣り合わせに記述します。

$ git log A..B C..D

ほとんどのコマンドでは2つのリビジョン範囲を指定しません。代わりに、接続された単一のコミットの組、つまりBまたはDのいずれかから到達可能であるが、AまたはCのどちらからも到達可能でないコミットの組に名前を付けます。線形履歴では、以下のようになります:

---A---B---o---o---C---D

AとBはCから到達可能であるため、これら2つの2ドット範囲記法で指定されたリビジョン範囲は単一のコミットDです。

Other <rev>^ Parent Shorthand Notations

コミットとその親コミットによって形成される組に名前を付けるために、マージコミットに特に役立つ他の3つの省略形が存在します。

r1^@ 表記は、 r1 のすべての親を意味します。

r1^! 表記にはコミット r1 が含まれますが、そのすべての親は除外されます。この表記自体は、単一のコミット r1 を示します。

<rev>^-[<n>] 表記には <rev> が含まれますが、 <n> 番目の親(つまり、 <rev>^<n>..<rev> の省略形)は除外されます。 <n> が指定されていない場合は <n> = 1 とみなします。これは通常、 <commit>^- を渡すだけで、マージコミット <commit>(<commit> 自体を含む)でマージされたブランチ内のすべてのコミットを取得できるマージコミットに役立ちます。

<rev>^<n> は単一のコミット親を指定することに関するものでしたが、これらの3つの表記はその親も考慮します。たとえば、 HEAD^2^@ と言うことはできますが、 HEAD^@^2 と言うことはできません。

Revision Range Summary

<rev>: <rev> から到達可能なコミット(つまり <rev> とその祖先)を含めます。
^<rev>: <rev> から到達可能なコミット(つまり <rev> とその祖先)を除外します。
<rev1>..<rev2>: <rev2> から到達可能なコミットを含めますが、 <rev1> から到達可能なコミットは除外します。 <rev1> または <rev2> のいずれかを省略すると、それらはそれぞれデフォルトで HEAD になります。
<rev1>...<rev2>: <rev1> または <rev2> のいずれかから到達可能なコミットを含めますが、両方から到達可能なコミットは除外します。 <rev1> または <rev2> のいずれかを省略すると、それらはそれぞれデフォルトで HEAD になります。
<rev>^@ 例: HEAD^@: 接尾辞 ^ の後にアットマーク(@)を付けることは、 <rev> のすべての親をリストすることと同じです(つまり、親から到達可能なものはすべて含まれますが、コミット自体は含まれません)。
<rev>^! 例: HEAD^!: 接尾辞 ^ の後に感嘆符(!)を付けることは、コミット <rev> を指定し、そのすべての親の前に ^ を付けてそれら(およびその祖先)を除外することと同じです。
<rev>^-<n> 例: HEAD^-, HEAD^-2: <rev>^<n>..<rev> と同等であり、 <n> が指定されていない場合は <n> = 1 です。

上記のLoeliger図解を使用したいくつかの例を以下に示します。表記の拡張と選択は、それぞれ段階が分かるようステップを踏んで説明してあります:

   Args   Expanded arguments    Selected commits
   D                            G H D
   D F                          G H I J D F
   ^G D                         H D
   ^D B                         E I J F B
   ^D B C                       E I J F B C
   C                            I J F C
   B..C   = ^B C                C
   B...C  = B ^F C              G H D E B C
   B^-    = B^..B
          = ^B^1 B              E I J F B
   C^@    = C^1
          = F                   I J F
   B^@    = B^1 B^2 B^3
          = D E F               D G H E F I J
   C^!    = C ^C^@
          = C ^C^1
          = C ^F                C
   B^!    = B ^B^@
          = B ^B^1 ^B^2 ^B^3
          = B ^D ^E ^F          B
   F^! D  = F ^I ^J D           G H D F

PARSEOPT

--parseopt モードでは、 git rev-parse は、オプションをもみもみして、Cビルトインと同じ機能をシェルスクリプトにもたらすのに役立ちます。これは、 getopt(1) と少し似た、オプションの正規化機能です(たとえば、単一のスイッチの集合を分割します)。

パースおよび理解できるオプションの仕様を標準入力で受け取り、引数を正規化されたものに置き換えるために、sh(1) eval に適した文字列をエコーします。エラーが発生した場合は、標準エラーストリームで使用状況を出力し、コード129で終了します。

注: 結果を eval に渡すときは、必ず引用符で囲んでください。例については、以下を参照してください。

Input Format

git rev-parse --parseopt 入力形式は完全にテキストベースです。 -- のみを含む行で区切られた2つの部分から構成されます。セパレーターの前の行(1つ以上である必要があります)が使用例に使用されます。区切り文字の後の行は、オプションを示しています。

オプションの各行の形式はいかのとおりです:

<opt-spec><flags>*<arg-hint>? SP+ help LF

<opt-spec>

この形式は、短いオプション1文字で、続いてコンマ(,)で区切り、そして長いオプション名があります。少なくとも短長のうち1つは必要ですが、両方揃ってなくてもいいです。 <flags> 文字を含めることはできません。 h,help や dry-run や f は正しい <opt-spec> の例です。

<flags>

<flags> とは * または = または ? または ! です。

オプションが引数を取る場合は、 = を使用します。
? の使用は、オプションがオプションの引数を取ることを意味します。オプションの引数を明確に解析できるようにするには、おそらく --stuck-long モードを使用する必要があります。
* を使用すると、このオプションが -h 引数に対して生成された使用法にリストされてはならないことを意味します。 gitcli(7) に記載されているように、 --help-all には表示されます。
！ を使用すると、対応する否定されたlongオプションを使用可能にしません。

<arg-hint>

<arg-hint> は、指定された場合、引数を取るオプションのヘルプ出力で引数の名前として使用されます。 <arg-hint> は最初の空白で終了します。複数単語の引数ヒントで単語を区切りたい時は、ダッシュを使う通例です。

スペースを取り除いた後の行の残りの部分は、オプションに関連付けられたヘルプとして使用されます。

空白行は無視され、この仕様に一致しない行はオプショングループヘッダーとして使用されます(意図的にそのような行を作成するためにはスペースで行を開始します)。

Example

OPTS_SPEC="\
some-command [<options>] <args>...

some-command does foo and bar!
--
h,help    show the help

foo       some nifty option --foo
bar=      some cool option --bar with an argument
baz=arg   another cool option --baz with a named argument
qux?path  qux may take a path argument but has meaning by itself

  An option group Header
C?        option C with an optional argument"

eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"

Usage text

上記の例で "$@" が -h または --help の場合、以下の使用法テキストが表示されます:

usage: some-command [<options>] <args>...

    some-command does foo and bar!

    -h, --help            show the help
    --foo                 some nifty option --foo
    --bar ...             some cool option --bar with an argument
    --baz <arg>           another cool option --baz with a named argument
    --qux[=<path>]        qux may take a path argument but has meaning by itself

An option group Header
    -C[...]               option C with an optional argument

SQ-QUOTE

--sq-quote モードでは、 git rev-parse は、 sh(1) eval に適した1行を標準出力にエコーします。この行は、 --sq-quote に続く引数を正規化することによって作成されます。引数をクォートする以外に何も行いません。

出力がシェル引用符で囲まれる前に、コマンド入力を git rev-parse によって通常どおりに解釈するには --sq オプションを参照してください。

Example

$ cat >your-git-script.sh <<\EOF
#!/bin/sh
args=$(git rev-parse --sq-quote "$@")   # quote user-supplied arguments
command="git frotz -n24 $args"          # and use it inside a handcrafted
                                        # command line
eval "$command"
EOF

$ sh your-git-script.sh "a b'c"

EXAMPLES

現在のコミットのオブジェクト名を出力します:
```
$ git rev-parse --verify HEAD
```
$REV シェル変数のリビジョンからコミットオブジェクト名を出力します:
```
$ git rev-parse --verify --end-of-options $REV^{commit}
```
$REV が空であるか、有効なリビジョンでない場合エラーになります。
上記と同様ですが…:
```
$ git rev-parse --default master --verify --end-of-options $REV
```
これは、 $REV が空の場合、masterからのコミットオブジェクト名が出力されます。

GIT

Part of the git(1) suite

git-rev-parse(1) Manual Page

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

Operation Modes

Options for `--parseopt`

Options for Filtering

Options for Output

Options for Objects

Options for Files

Other Options

SPECIFYING REVISIONS

SPECIFYING RANGES

Commit Exclusions

Dotted Range Notations

Other <rev>^ Parent Shorthand Notations

Revision Range Summary

PARSEOPT

Input Format

Example

Usage text

SQ-QUOTE

Example

EXAMPLES

GIT

git-rev-parse(1) Manual Page

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

Operation Modes

Options for --parseopt

Options for Filtering

Options for Output

Options for Objects

Options for Files

Other Options

SPECIFYING REVISIONS

SPECIFYING RANGES

Commit Exclusions

Dotted Range Notations

Other <rev>^ Parent Shorthand Notations

Revision Range Summary

PARSEOPT

Input Format

Example

Usage text

SQ-QUOTE

Example

EXAMPLES

GIT

Options for `--parseopt`