SYNOPSIS

'git shortlog' [<options>] [<revision-range>] [[--] <path>...]
git log --pretty=short | 'git shortlog' [<options>]

DESCRIPTION

「git log」の出力を、リリースアナウンスに含めるのに適した形式で要約します。各コミットは、作者とタイトルごとにグループ化されます。

加えて、「[PATCH]」はコミットの説明から削除されます。

コマンドラインでリビジョンが渡されず、かつ、標準入力が端末ではないかまたは現在のブランチがない場合、「git shortlog」は、現在のリポジトリを参照せずに、標準入力から読み取られたログの概要を出力します。

OPTIONS

-n
--numbered

Sort output according to the number of commits per author instead of author alphabetic order.

-s
--summary

Suppress commit description and provide a commit count summary only.

-e
--email

Show the email address of each author.

--format[=<format>]

Instead of the commit subject, use some other information to describe each commit. <format> can be any string accepted by the --format option of git log, such as * [%h] %s. (See the "PRETTY FORMATS" section of git-log(1).) 

Each pretty-printed commit will be rewrapped before it is shown.
--date=<format>

Show dates formatted according to the given date string. (See the --date option in the "Commit Formatting" section of git-log(1)). Useful with --group=format:<format>.

--group=<type>

Group commits based on <type>. If no --group option is specified, the default is author. <type> is one of:

  • author : コミットは作成者ごとにグループ化されます

  • committer : コミットはコミッターによってグループ化されます( -c と同じ)

  • trailer:<field> : <field> は大文字と小文字を区別しないコミットメッセージトレーラーとして解釈されます(git-interpret-trailers(1) 参照)。たとえば、プロジェクトで Reviewed-by のトレーラーを使用している場合、 git shortlog -ns --group=trailer:reviewed-by を使用して誰がレビューしているかを確認できます。

  • format:<format> : <format> は git log の --format オプションで受け入れられる任意の文字列です。 (git-log(1) の「PRETTY FORMATS」セクション参照。)

    注意: トレーラーを含まないコミットはカウントされないことに注意してください。同様に、複数のトレーラーを使用したコミット(複数のサインオフなど)は、複数回カウントされる場合があります(ただし、そのコミットの一意のトレーラー値ごとに1回のみです)。

    shortlog は、各トレーラー値を name <email> ID としてパースしようとします。成功すると、mailmapが適用され、 --email オプションが指定されていない限りemailは省略されます。値をIDとして解析できない場合は、その文言通りに取得されます。

--group が複数回指定されている場合、コミットは各値でカウントされます(ただし、そのコミットの一意の値ごとに1回だけカウントされます)。 たとえば、 git shortlog --group=author --group=trailer:co-authored-by は、authorとco-authorの両方をカウントします。

-c
--committer

This is an alias for --group=committer.

-w[<width>[,<indent1>[,<indent2>]]]

Linewrap the output by wrapping each line at width. The first line of each entry is indented by indent1 spaces, and the second and subsequent lines are indented by indent2 spaces. width, indent1, and indent2 default to 76, 6 and 9 respectively.

widthが 0 (ゼロ)の場合、出力の行を折り返すことなくインデントします。

<revision-range>

指定のリビジョン範囲のコミットのみを表示します。 <revision-range> が指定されていない場合、デフォルトで HEAD (つまり、現在のコミットにつながる履歴全体)になります。 origin..HEAD は、現在のコミット(つまり、 HEAD )から到達可能なすべてのコミットを指定しますが、 origin からは指定しません。 <revision-range> のスペルの完全なリストについては、 gitrevisions(7) の「Specifying Ranges」セクションを参照してください。

[--] <path>…

指定されたパスに一致するファイルがどのように作成されたかを説明するのに十分なコミットのみを検討してください。

混乱が生じた場合、パスをオプションまたはリビジョン範囲から分離するために、パスの前に -- を付ける必要がある場合があります。

Commit Limiting

ここで説明されている特別な表記法を使用してリストする必要があるコミットの範囲を指定することに加えて、追加のコミット制限が適用される場合があります。

より多くのオプションを使用すると、通常、出力がさらに制限されます(たとえば、 --since=<date1> は <date1> より新しいコミットに制限され、 --grep=<pattern> と一緒に使用すると、ログメッセージに <pattern> と一致する行があるコミットにさらに制限されます)。

注意: これらは、 --reverse などのコミット順序およびフォーマットオプションの前に適用されることに注意してください。

-<number>
-n <number>
--max-count=<number>

出力するコミットの数を制限します。

--skip=<number>

コミット出力の表示を開始する前に、number 個のコミットをスキップします。

--since=<date>
--after=<date>

指定の日付よりも新しいコミットを表示します。

--since-as-filter=<date>

特定の日付より新しいすべてのコミットを表示します。 これは、特定の日付より古い最初のコミットで停止するのではなく、範囲内のすべてのコミットを訪問します。

--until=<date>
--before=<date>

指定の日付より古いコミットを表示します。

--author=<pattern>
--committer=<pattern>

コミット出力を、指定されたパターン(正規表現)に一致する作者(author)/コミッター(committer)ヘッダー行を持つものに制限します。複数の --author=<pattern> がある場合、作者が指定されたパターンのいずれかに一致するコミットが選択されます(複数の --committer=<pattern> の場合も同様)。

--grep-reflog=<pattern>

コミット出力を、 指定されたパターン(正規表現)に一致するreflogエントリを持つものに制限します。 複数の --grep-reflog を使用すると、 指定されたパターンのいずれかに一致するreflogメッセージを持つコミットが選択されます。 --walk-reflogs が使用されていない限り、 このオプションを使用するとエラーになります。

--grep=<pattern>

コミット出力を、 指定されたパターン(正規表現)にマッチする単一のログメッセージを持つモノに制限します。 複数の --grep=<pattern> を使用すると、 指定されたパターンのいずれかにメッセージがマッチするコミットが選択されます(全てにマッチするコミットだけを選択したい場合、--all-match を参照してください)。

--notes が有効な場合、ノートからのメッセージは、ログメッセージの一部であるかのようにマッチングされます。

--all-match

コミット出力を、少なくとも1つに一致するものではなく、指定されたすべての --grep に一致するものに制限します。

--invert-grep

コミット出力を、 --grep=<pattern> で指定されたパターンとマッチしない単一のログメッセージを持つモノに制限します。

-i
--regexp-ignore-case

大文字小文字に関係なく、正規表現の制限パターンに一致します。

--basic-regexp

制限パターンを基本正規表現として扱います。これがデフォルトです。

-E
--extended-regexp

制限パターンを、デフォルトの基本正規表現の代わりに拡張正規表現として扱います。

-F
--fixed-strings

制限パターンを固定文字列として扱います(パターンを正規表現として解釈しないでください)。

-P
--perl-regexp

制限パターンをPerl互換の正規表現として扱います。

これらのタイプの正規表現のサポートは、コンパイル時オプションに依存します。Gitが当該のサポート付きでコンパイルされていない場合、このオプションを使うと、Gitが終了(die)します。

--remove-empty

指定されたパスがツリーから見えなくなったら停止(stop)します。

--merges

マージコミットのみを出力します。これは --min-parents=2 とまったく同じです。

--no-merges

複数の親を持つコミットを出力しない。これは --max-parents=1 とまったく同じです。

--min-parents=<number>
--max-parents=<number>
--no-min-parents
--no-max-parents

量の多少に関わらず、 とにかく複数の親コミットがあるコミットのみを表示します。特に、 --max-parents=1 は --no-merges と同じであり、 --min-parents=2 は --merges と同じです。 --max-parents=0 はすべてのルートコミットを提供し、 --min-parents=3 はすべてのタコ足マージ(octopus merges)を示します。

--no-min-parents と --no-max-parents は、これらの制限を(制限なしに)再度リセットします。同等の形式は、 --min-parents=0 (すべてのコミットに0個以上の親があります)および --max-parents=-1 (マイナスの数は上限がないことを示します)です。

--first-parent

インクルードするコミットを探すとき、マージ・コミットの最初の親コミットのみをたどります。 このオプションは、特定のトピックブランチの進化を表示するときに、より良い概要を提供できます。トピックブランチへのマージは、時々更新されるアップストリームに調整することだけである傾向があり、このオプションを使用すると、そのようなマージによって履歴に取り込まれた個々のコミットを無視できます。

--exclude-first-parent-only

( ^ を使用して)除外するコミットを見つけるときは、 判明したマージ・コミットの最初の親コミットのみに従います。 任意のマージが有効なトピック・ブランチの変更になる可能性がある場合、 これを使用して、 リモート・ブランチから分岐したポイントからトピック・ブランチ内の一連の変更を見つけることができます。

--not

次の --not までの後続のすべてのリビジョン指定子について、 ^ プレフィックス(またはその欠落)の意味を反転します。 コマンドラインで --stdin より前で使用すると、 stdin を介して渡されたリビジョンは影響を受けません。 逆に、 標準入力経由で渡された場合、 コマンドラインで渡されたリビジョンは影響を受けません。

--all

refs/ 内のすべてのrefが HEAD とともに、コマンドラインに <commit> としてリストされているかのように見せかけます。

--branches[=<pattern>]

refs/heads 内のすべてのrefがコマンドラインに <commit> としてリストされているかのように見せかけます。 <pattern> が指定されている場合、ブランチを指定されたシェルグロブ(shell glob)に一致するものに制限します。パターンに "?" または "*" または "[" がない場合、最後に "/*" が含まれます。

--tags[=<pattern>]

refs/tags 内のすべてのrefがコマンドラインに <commit> としてリストされているかのように見せかけます。 <pattern> が指定されている場合は、指定されたシェルグロブ(shell glob)に一致するタグにタグを制限します。パターンに "?" または "*" または "[" がない場合、最後に "/*" が含まれます。

--remotes[=<pattern>]

refs/remotes 内のすべてのrefがコマンドラインに <commit> としてリストされているかのように見せかけます。 <pattern> が指定されている場合、リモート追跡ブランチを指定されたシェルグロブ(shell glob)に一致するものに制限します。パターンに "?" または "*" または "[" がない場合、最後に "/*" が含まれます。

--glob=<glob-pattern>

シェルグロブ <glob-pattern> に一致するすべてのrefがコマンドラインに <commit> としてリストされているかのように見せかけます。先頭の 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/ で始める必要があります。末尾の "/*" を意図している場合は、明示的に指定する必要があります。

--exclude-hidden=[fetch|receive|uploadpack]

transfer.hideRefs とともに適切な fetch.hideRefs 設定または receive.hideRefs 設定または uploadpack.hideRefs 設定を参照して、 git-fetch または git-receive-pack または git-upload-pack によって非表示になるrefを含めないでください(git-config(1) 参照)。 このオプションはそれ以降疑似参照オプション --all または --glob に影響し、 それらの処理後にクリアされます。

--reflog

reflogsで言及されているすべてのオブジェクトがコマンドラインに <commit> としてリストされているかのように見せかけます。

--alternate-refs

代替リポジトリのref先端として言及されているすべてのオブジェクトがコマンドラインにリストされているかのように見せかけます。 代替リポジトリは、 オブジェクトディレクトリが objects/info/alternates で指定されているリポジトリです。 インクルードされたオブジェクトのセットは、 core.alternateRefsCommand などによって変更できます。 git-config(1)を参照してください。

--single-worktree

デフォルトでは、 作業ツリーが複数ある場合、 --all と --reflog と --indexed-objects では、 すべての作業ツリーが検査されます(git-worktree(1)を参照)。 このオプションは、 現在の作業ツリーのみを調べるように強制します。

--ignore-missing

入力に無効なオブジェクト名が含まれている場合、そもそもその不正な入力が行われていないかのように見せかけます。

--bisect

コマンドラインで、bad bisection ref refs/bisect/bad がリストされ、その後に --not と good bisection ref refs/bisect/good-* が続くかのように見せかけます。

--stdin

コマンドラインから引数を取得するだけでなく、 標準入力からも引数を読み込みます。 これはコミットや、--all や --glob= のような疑似オプションを受け付けます。 -- 区切り文字が現れた場合、 それに以降の入力はパス(paths)として扱われ、 出力結果を制限するために使用されます。 標準入力経由で読み取られる --not のようなフラグは、 同一のやり方である標準入力経由で読み取られて渡された引数に対してのみ考慮され、 --stdin の後ろに置いたコマンド・ライン引数には影響しません。

--cherry-mark

--cherry-pick（以下を参照）と同様ですが、同等のコミットを省略せずに = と印し、同等でないコミットを + と印します。

--cherry-pick

コミットの組を対称差(symmetric difference)に制限する場合、「反対側」の別のコミットと同じ変更を導入するコミットを省略します。

たとえば、A と B の2つのブランチがある場合、それらの片側だけですべてのコミットを一覧表示する通常の方法は、 --left-right を使用することです(--left-right オプションの説明の以下の例を参照してください)。ただし、他のブランチからは(ブランチAと重複しない)厳選されたコミットが表示されます(たとえば、「3rd onb」はブランチAからチェリーピックされる可能性があります)。このオプションを使用すると、そのようなコミットのペアは出力から除外されます。

--left-only
--right-only

リストは、 対称差のそれぞれの側でのみコミットします。 つまり、 --left-right で < と印されるのだけか、あるいは --left-right で > と印されるものだけです。

たとえば、 --cherry-pick --right-only A…B は、 A にある、 または A のコミットとパッチと同等のコミットを B から省略します。 つまり、 これは git cherry A B からの + コミットをリストします。 より正確に書くと、 --cherry-pick --right-only --no-merges により正確なリストを提供します。

--cherry

--right-only --cherry-mark --no-merges の同義語です。 出力を私たちの側のコミットに制限し、 フォークされた履歴の反対の側に適用されたものを、 git cherry upstream mybranch と同様に git log --cherry upstream…mybranch でマークするのに役立ちます。

-g
--walk-reflogs

コミットの祖先チェーンをたどる代わりに、 reflogエントリを最新のものから古いものに移動します。 このオプションを使用する場合、 除外するコミットを指定することはできません(つまり、 ^commit や commit1..commit2 や commit1...commit2 表記は使用できません)。

(明らかな理由で、) oneline と reference 以外の --pretty 形式では、 これにより、 出力にreflogから取得された2行の追加情報が含まれます。 出力のreflog指定子は、 ref@{<Nth>} ( <Nth> はreflogの逆時系列インデックス(reverse-chronological index)) または ref@{<timestamp>} (そのエントリを <timestamp> 付で)として表示されます。 表示は下記のいくつかのルールに依存します:

  1. 開始点が ref@{<Nth>} として指定されている場合は、 インデックス形式を表示します。

  2. 開始点が ref@{now} として指定されている場合は、タイムスタンプ形式を表示します。

  3. 上記のどちらも使用されていないが、コマンドラインで --date が指定されている場合は、 --date で要求された形式でタイムスタンプを表示します。

  4. それ以外の場合は、インデックス形式を表示します。

--pretty = oneline では、コミットメッセージの前にこの情報が同じ行に付けられます。このオプションを --reverse と組み合わせることはできません。 git-reflog(1)も参照してください。

--pretty=reference では、この情報はまったく表示されません。

--merge

範囲 HEAD…<other> 内の競合したパスに触れる(touch)コミットを表示します。 ここで、<other> は MERGE_HEAD または CHERRY_PICK_HEAD または REVERT_HEAD または REBASE_HEAD のいずれかの最初の既存の擬似ref(pseudoref)です。 インデックスにマージされていないエントリがある場合にのみ機能します。 このオプションを使用すると、 三者間マージからの競合を解決するときに関連するコミットを表示できます。

--boundary

除外された境界コミットを出力します。 境界コミットの前には - が付いています。

History Simplification

特定の<path>を変更するコミットなど、履歴の一部のみに関心がある場合があります。ただし、「履歴の簡略化」(History Simplification)は2つの部分から成ります。履歴を簡略化するためにはさまざまな戦略があるためです。その1つはコミットの選択であり、もう1つはそれを行う方法です。

以下のオプションは、表示するコミットを選択します:

<paths>

<paths> で指定したパスを変更するコミットが選択されます。

--simplify-by-decoration

いくつかのブランチまたはタグによって参照されるコミットが選択されます。

注意: 意味のある重要な履歴のために、追加のコミットを表示できることに注意してください。

以下のオプションは、簡略化の実行方法に影響します。

Default mode

履歴を、ツリーの最終状態を説明する最も単純な履歴に単純化します。最終結果が同じである場合(つまり、同じコンテンツのブランチをマージする場合)、いくつかの傍流ブランチ(side branches)を削除するため、最も単純です。

--show-pulls

デフォルトモードからのすべてのコミットを含めますが、最初の親へのTREESAMEではなく、後の親へのTREESAMEであるマージコミットも含めます。このモードは、ブランチに変更を「最初に導入した」マージコミットを表示するのに役立ちます。(訳注:TREESAME=pathspecが全く同一であるツリー)

--full-history

デフォルトモードと同じですが、一部の履歴を削除しません。

--dense

選択したコミットのみが表示され、重大で意味のある履歴を持つコミットもいくつか表示されます。

--sparse

簡略化された履歴内のすべてのコミットが表示されます。

--simplify-merges

このマージに寄与する選択されたコミットがないため、結果の履歴からいくつかの不要なマージを削除するための --full-history への追加オプション。

--ancestry-path[=<commit>]

表示するコミットの範囲を指定すると(例: commit1..commit2 または commit2 ^commit1)、その範囲内で <commit> の祖先、<commit> の子孫、または <commit> 自身であるコミットのみを表示します。 コミットが指定されていない場合は、commit1 (範囲の除外部分) を <commit> として使用します。 複数回渡すことができます。 その場合、あるコミットが指定されたコミットのいずれかであるか、それらのいずれかの祖先または子孫である場合、そのコミットは含まれます。

より詳細な説明は以下のとおりです。

<paths> として foo を指定したとします。 foo を変更するコミットを !TREESAME と呼び、 それ以外のコミットを TREESAME と呼びます。 ( foo でフィルタリングされた差分では、それぞれ異なって見えたりたり同じに見えたりします。）

以下、簡略化設定の違いを説明するために、同じ履歴例を使います。このコミットグラフでは、ファイル foo をフィルタリングしていると想定しています:

          .-A---M---N---O---P---Q
         /     /   /   /   /   /
        I     B   C   D   E   Y
         \   /   /   /   /   /
          `-------------'   X

履歴 A---Q の水平線は、各マージの最初の親と見なされます。その各コミットは以下のとおりです:

  • I は最初のコミットであり、ファイル foo が内容 “asdf” で存在し、ファイル quux は内容 “quux” で存在します。最初のコミットは空のツリーと比較されるため、I は !TREESAME です。

  • A では、 foo には “foo” だけが含まれています。

  • B には A と同じ変更が含まれています。 よって、 そのマージ M は些細(trivial)なことであり、 したがって、 その全ての親に対して TREESAME です。

  • C は foo を変更しませんが、そのマージ N は foo を “foobar” に変更するので、 どの親に対しても TREESAME ではありません。

  • D は foo を “baz” に設定します。そのマージ O は、 N と D から “foobarbaz” への文字列を結合します。 つまり、どの親に対しても TREESAME ではありません。

  • E は quux を “xyzzy” に変更し、そのマージ P は文字列を “quuxxyzzy” に結合します。 P は O に対して TREESAME ですが、 E に対してはそうではありません。

  • X は、新ファイル side を追加し、 Y がそれを変更した独立したルートコミットです。 Y は X へのTREESAMEです。そのマージ Q は P に side を追加し、 Q は P にはTREESAMEですが、Y に対してはそうではありません。

rev-list は、 --full-history および/または、( --parents または --children を介して)親の書き換えが使用されているかどうかに基づいて、コミットを含めたり除外したりして、履歴を逆方向にウォークスルーします。以下の設定が可能です。

Default mode

コミットは、どの親に対してもTREESAMEでない場合に含まれます(これは変更できますが、以下の --sparse を参照してください)。コミットがマージであり、一方の親に対するTREESAMEであった場合は、その親のみをフォローします。(TREESAMEの親が複数ある場合でも、そのうちの1つだけをフォローします)。それ以外の場合は、すべての親をフォローします。

これにより、以下のようになります:

          .-A---N---O
         /     /   /
        I---------D

TREESAMEの親のみに従うルールが利用可能な場合は、 B を検討対象から完全に削除したことに注意してください。 C は N を介して考慮されましたが、しかしそれはTREESAMEです。ルートコミットは空のツリーと比較されるため、 I は !TREESAME です。

親子関係は --parents でのみ表示されますが、デフォルトモードで選択されたコミットには影響しないため、親の行を示しました。

--full-history without parent rewriting

このモードはデフォルトとはある一点で異なります：マージのすべての親を常に追跡する点です。 たとえそれが親の1つに対して TREESAME であってもです。 マージの複数の側に含まれるコミットがあったとしても、 それはマージ自体が含まれていることを意味するわけではありません。 この例では以下のようになります 

        I  A  B  N  D  O  P  Q

M は、両方の親にとってTREESAMEであるため、除外されました。 E と C と B をすべて巡りましたが、 そのうちの B だけが !TREESAME だったので、 それ以外の E と C は表示されません。

注意: 親の書き換え(rewrite)がないと、コミット間の親子関係について話す(talk)ことは実際には不可能であるため、それらが切断されている(disconnected)ことを示していることに注意してください。

--full-history with parent rewriting

通常のコミットは !TREESAME の場合にのみ含まれます(これは変更できますが、以下の --sparse を参照してください)。

マージは常に含まれます。ただし、親リストは書き直されます。各親に沿って、自身が含まれていないコミットを削除します。 これにより以下のようになります

          .-A---M---N---O---P---Q
         /     /   /   /   /
        I     B   /   D   /
         \   /   /   /   /
          `-------------'

これを書き直し無しの --full-history と比較してください。 E は TREESAME であるため削除されましたが、 Pの親リストは E の親 I を含むように書き直されていることに注意してください。 C と N および X と Y と Q についても同じことが起こりました。

上記の設定に加えて、あなたはTREESAMEが包含に影響を与えるかどうかを変更できます:

--dense

巡ったコミットは、親にとってTREESAMEでない場合に含まれます。

--sparse

巡ったすべてのコミットが含まれます。

--full-history がなくても、これによりマージが単純化されることに注意してください。親の1つがTREESAMEの場合、その1つだけに従うため、マージの反対側を巡ることはありません。

--simplify-merges

最初に、親を書き換えた --full-history と同じ方法で履歴グラフを作成します(上記を参照)。

それから、以下のルールに従って、各コミット C を最終履歴内の置換 C' に単純化します:

  • C' を C にセットします。

  • C' の各親 P をその簡略化された P' に置き換えます。その過程で、他の親の祖先であるか、ルートである親を削除すると、TREESAMEが空のツリーにコミットされ、重複が削除されますが、TREESAMEであるすべての親を削除しないように注意してください。

  • この親の書き換え後、 C' がルートまたはマージコミット(0または >1 の親を持つ)、境界コミット、または !TREESAMEである場合、それは残ります。それ以外の場合は、唯一の親に置き換えられます。

この効果は、親の書き換えを使用した --full-history と比較することで最もよく示されます。例は以下のようになります:

          .-A---M---N---O
         /     /       /
        I     B       D
         \   /       /
          `---------'

注意: --full-history に対する N と P と Q の主な違いに注意してください:

  • N の親リストは、他の親 M の祖先であるため、 I が削除されました。それでも、 !TREESAME なので N が残りました。

  • P の親リストも同様に I が削除されました。 P は、親が1つで TREESAMEであるため、完全に削除されました。

  • Q の親リストでは、 Y が X に簡略化されていました。その後、 X はTREESAMEルートであったため、削除されました。 Q は、親が1つで TREESAMEであるため、完全に削除されました。

利用可能な別の簡略化モードがあります:

--ancestry-path[=<commit>]

表示されるコミットを <commit> の祖先、または <commit> の子孫、または <commit> 自身に制限します。

ユースケースの例として、以下のコミット履歴について考えます:

            D---E-------F
           /     \       \
          B---C---G---H---I---J
         /                     \
        A-------K---------------L--M

通常の D..M は、 M の祖先であるコミットのセットを計算しますが、 D の祖先であるコミットは除外します。 これは、「 M には D には存在しなかったものがある」という意味で、 D 以降の M に至るまでの歴史に何が起こったのかを知るのに役立ちます。この例の結果は、 A と B (そしてもちろん D 自体)を除くすべてのコミットになります。

ただし、 M のコミットが D で入ったバグで汚染されており、修正が必要な場合は、実際には D の子孫である D..M のサブセットのみを表示する必要があります。つまり、 C と K を除外します。これはまさに --ancestry-path オプションが行うことです。これを D..M 範囲に適用すると、以下のようになります:

                E-------F
                 \       \
                  G---H---I---J
                               \
                                L--M

--ancestry-path の代わりに --ancestry-path=D を使用することもできます。これは、D..M 範囲に適用された場合と同じことを意味しますが、より明示的です。

代わりに、この範囲内の特定のトピックに関心があり、そのトピックによって影響を受けるすべてのコミットに関心がある場合、祖先パスにそのトピックを含む D..M のサブセットのみを表示したい場合があります。 たとえば、--ancestry-path=H D..M を使用すると、以下のようになります:

                E
                 \
                  G---H---I---J
                               \
                                L--M

一方、--ancestry-path=K D..M は以下のようになります

                K---------------L--M

別のオプション --show-pulls について説明する前に、新しいサンプル履歴を作成する必要があります。

簡略化された履歴を見るときにユーザーが直面する一般的な問題は、ファイルを変更したことがわかっているコミットが、ファイルの簡略化された履歴に表示されないことです。そこで、新しい例を示し、その場合に --full-history や --simplify-merges などのオプションがどのように機能するかを示しましょう。

          .-A---M-----C--N---O---P
         /     / \  \  \/   /   /
        I     B   \  R-'`-Z'   /
         \   /     \/         /
          \ /      /\        /
           `---X--'  `---Y--'

この例では、 I が file.txt を作成し、それが A と`B` と X にてさまざまな方法で変更されたとします。ひとり親のコミット C と Z と Y は file.txt を変更していません。マージコミット M は、マージの競合を解決して、 A と B の両方の変更を含めることによって作成されたため、どちらにもTREESAMEではありません。ただし、マージコミット R は、 M の file.txt の内容を無視し、 X の file.txt の内容のみを取得することによって作成されました。 したがって、 R は X へのTREESAMEですが、 M はそうではありません。最後に、 N を作成するための自然なマージ解決は、 R で file.txt の内容を取得することです。したがって、 N は C ではなく R へのTREESAMEです。マージコミット O と P は、最初の親にはTREESAMEですが、2番目の親である Z と Y にはついてはそうではありません。

デフォルト・モードを使用する場合、 N と R は両方ともTREESAMEの親を持っているため、 TREESAMEの親へ向かう経路(edges)はウォークされ、 それ以外のTREESAMEでない経路は無視されます。 結果の履歴グラフは以下のとおりです:

        I---X

--full-history を使用する場合、Gitはすべての経路(edge)を巡ります。これにより、コミット A と B と マージ M が検出されますが、マージコミット O と P も明らかになります。 親を書き換えると、結果のグラフは以下のようになります:

          .-A---M--------N---O---P
         /     / \  \  \/   /   /
        I     B   \  R-'`--'   /
         \   /     \/         /
          \ /      /\        /
           `---X--'  `------'

ここで、マージコミット O と P は、実際には file.txt への変更を提供しなかったため、余分なノイズを提供します。古いバージョンの file.txt に基づいたトピックのみをマージしました。これは、多くの寄稿者が並行して作業し、トピックブランチを単一のトランクに沿ってマージするワークフローを使用するリポジトリの一般的な問題です。 --full-history の結果には、関連のない多くのマージが表示されます。

--simplify-merges オプションを使用すると、コミット O と P が結果から消えます。 これは、 O と P の書き直された2番目の親が、最初の親から到達可能であるためです。これらの経路(edges)が削除されると、コミットは、親にとってTREESAMEである単一の親のコミットのように見えます。これはコミット N にも発生し、以下のような履歴ビューが表示されます:

          .-A---M--.
         /     /    \
        I     B      R
         \   /      /
          \ /      /
           `---X--'

このビューでは、 A と B と X からの重要なひとり親の変更がすべて表示されます。また、慎重に解決されたマージ M とそれほど慎重に解決されていないマージ R も表示されます。これは通常、コミット A と B がデフォルトのビューの履歴から「消えた」理由を判断するのに十分な情報です。ただし、このアプローチにはいくつかの問題があります。

最初の問題はパフォーマンスです。以前のオプションとは異なり、 --simplify-merges オプションでは、単一の結果を返す前にコミット履歴全体をウォークする必要があります。これにより、非常に大規模なリポジトリでこのオプションを使用するのが難しくなる可能性があります。

2番目の問題は監査に関するものです。 多くの寄稿者が同じリポジトリで作業している場合、 どのマージ・コミットが重要なブランチに変更を導入したかが重要です。 上記の問題のあるマージ R は、 重要なブランチにマージするために使用されたマージ・コミットではない可能性が高いです。 代わりに、 R と X を重要なブランチにマージするためにマージ N が使われました。 このコミットのコミット・メッセージには、 なぜ変更 X が A と B からの変更を上書きするようになった理由に関する情報が含まれている可能性があります。

--show-pulls

デフォルトの履歴に表示されるコミットに加えて、最初の親にはTREESAMEではなく、後の親にはTREESAMEである各マージコミットを表示します。

マージコミットが --show-pulls に含まれている場合、マージは別のブランチから変更を「プル」したかのように扱われます。この例で --show-pulls を使用すると(他のオプションは使用しない場合、)結果のグラフは以下のようになります:

        I---X---R---N

ここで、コミット X と R をそれぞれベースブランチにプルしたため、マージコミット R と N が含まれています。これらのマージは、コミット A と B がデフォルトの履歴に表示されない理由です。

--show-pulls が --simplify-merges とペアになっている場合、グラフには必要なすべての情報が含まれます:

          .-A---M--.   N
         /     /    \ /
        I     B      R
         \   /      /
          \ /      /
           `---X--'

M は R から到達可能であるため、 N から M への経路(edge)が単純化されていることに注意してください。ただし、 N は、変更 R をメインブランチに「プル」したため、重要なコミットとして履歴に表示されます。

--simplify-by-decoration オプションを使用すると、タグで参照されていないコミットを省略して、履歴のトポロジの全体像のみを表示できます。コミットは、(1)タグによって参照されている場合、または (2)コマンドラインで指定されたパスの内容を変更した場合に、!TREESAMEとしてマークされます(つまり、上記の履歴簡略化ルールの後に保持されます)。他のすべてのコミットはTREESAMEとしてマークされます(簡略化される可能性があります)。

MAPPING AUTHORS

See gitmailmap(5).

注意: (標準入力でログの内容を処理するため) git shortlog がリポジトリの外部で実行される場合、現在のディレクトリで .mailmap ファイルが検索されることに注意してください。

GIT

Part of the git(1) suite