SYNOPSIS

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

DESCRIPTION

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

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

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

OPTIONS

-n
--numbered

作者のアルファベット順ではなく、作者のコミット数に従って出力を並べ替えます。

-s
--summary

コミットの説明を抑制し、コミット数の要約のみを提供します。

-e
--email

各作者のメールアドレスを表示します。

--format[=<format>]

コミットの件名の代わりに、他の情報を使用して各コミットを説明します。 <format> は、 * [%h] %s など 、 git log の --format オプションで受け入れられる任意の文字列にすることができます。 (git-log(1) の「PRETTY FORMATS」セクションを参照してください。) 

pretty-printされた各コミットは、表示される前に再ラップ(rewrapp)されます。
--group=<type>

グループは <type> に基づいてコミットします。 --group オプションが指定されていない場合、デフォルトは author です。 <type> は以下のいずれかです:

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

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

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

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

--group=committer のエイリアスです。

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

各行を width で折り返すことにより、出力を行折り返します。各エントリの最初の行は indent1 スペースでインデントされ、2行目以降は indent2 スペースでインデントされます。 width と indent1 と indent2 のデフォルトは、それぞれ76と6と9です。

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>

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

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

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

--not

次に現れる --not までの間、後続のすべてのリビジョン指定子の ^(カレット)接頭辞(またはその欠如)の意味を逆にします。

--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/ で始める必要があります。末尾の "/*" を意図している場合は、明示的に指定する必要があります。

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

コマンドラインにリストされている <commit> に加えて、標準入力からそれらを読み取ります。 -- 区切り文字が表示された場合は、コミットの読み取りを停止し、パスの読み取りを開始して結果を制限します。

--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} (そのエントリのタイムスタンプ付き)として表示されます。表示は下記のいくつかのルールに依存します:

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

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

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

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

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

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

--merge

マージが失敗した後、競合があり、マージするすべてのheadに存在しないファイルに関連(touch)するrefを表示します。

--boundary

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

History Simplification

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

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

<paths>

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

--simplify-by-decoration

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

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

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

Default mode

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

--show-pulls

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

--full-history

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

--dense

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

--sparse

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

--simplify-merges

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

--ancestry-path

表示するコミットの範囲が指定されている場合(たとえば、 commit1..commit2 または "commit2 ^commit1")、 commit1 と commit2 の間の祖先チェーンに直接存在するコミットのみ、つまり、 commit1 の子孫であり、 commit2 の祖先であるコミットを表示します。

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

<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 は些細なことであり、したがってすべての親にとって TREESAME です。

  • C は foo を変更しませんが、そのマージ N はそれを “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

このモードは、デフォルトとはある一点で異なります。つまり、いずれかの親に対してTREESAMEであっても、常にマージのすべての親に従います。マージの複数の側にコミットが含まれている場合でも、これはマージ自体が含まれていることを意味するものではありません！ 例では以下のようになります。 

        I  A  B  N  D  O  P  Q

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

注意: 親の書き換え(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

表示されるコミットを、指定されたコミット範囲内の “from” コミットと “to” コミットの間の祖先チェーンに直接あるコミットに制限します。つまり、 “to” コミットの祖先であるコミットと “from” コミットの子孫であるコミットのみを表示します。

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

            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

別のオプション --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の親を持っているため、これらのエッジはウォークされ、他のエッジは無視されます。結果の履歴グラフは以下のとおりです:

        I---X

--full-history を使用する場合、Gitはすべてのエッジを巡ります。これにより、コミット 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番目の親が、最初の親から到達可能であるためです。これらのエッジが削除されると、コミットは、親にとってTREESAMEである単一の親のコミットのように見えます。これはコミット N にも発生し、以下のような履歴ビューが表示されます:

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

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

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

2番目の問題は監査の1つです。多くの寄稿者が同じリポジトリで作業している場合、どのマージコミットが重要なブランチに変更を導入したかが重要です。上記の問題のあるマージ R は、重要なブランチにマージするために使用されたマージコミットではない可能性があります。 代わりに、マージ N を使用して R と X を重要なブランチにマージしました。このコミットには、変更 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 へのエッジが単純化されていることに注意してください。ただし、 N は、変更 R をメインブランチに「プル」したため、重要なコミットとして履歴に表示されます。

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

MAPPING AUTHORS

See gitmailmap(5).

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

GIT

Part of the git(1) suite