Spec-Zone.ru › Git

git-shortlog

Название

git-shortlog — сводка вывода git log

Синтаксис

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

Описание

Сводит вывод git log в формат, подходящий для включения в объявления о выпусках. Каждый коммит будет сгруппирован по автору и заголовку.

Кроме того, «[PATCH]» будет удалено из описания коммита.

Если в командной строке не указаны ревизии, а стандартный ввод не является терминалом или текущая ветка отсутствует, git shortlog выведет сводку журнала, прочитанного из стандартного ввода, без обращения к текущему репозиторию.

Параметры

-n
--numbered

Сортировать вывод по количеству коммитов каждого автора, а не по алфавиту имён авторов.

-s
--summary

Не выводить описание коммитов и показывать только сводку с их количеством.

-e
--email

Показывать адрес электронной почты каждого автора.

--format[=<format>]

Вместо темы коммита использовать другие сведения для описания каждого коммита. <format> может быть любой строкой, принимаемой параметром --format команды git log, например * [%h] %s. (См. раздел PRETTY FORMATS в git-log[1].)

Перед выводом каждый коммит в форматированном виде будет переноситься по строкам.

--date=<format>

Показывать даты в формате, заданном указанной строкой даты. (См. параметр --date в разделе Commit Formatting в git-log[1].) Полезно в сочетании с --group=format:<format>.

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

    Обратите внимание: коммиты без такого завершающего элемента не учитываются. Аналогично, коммиты с несколькими завершающими элементами (например, с несколькими отметками о подтверждении) могут учитываться более одного раза (но только один раз для каждого уникального значения завершающего элемента в коммите).

    Shortlog попытается разобрать каждое значение завершающего элемента как идентификатор name <email>. Если это удастся, будет применена mailmap, а адрес электронной почты будет опущен, если не указан параметр --email. Если значение не удаётся разобрать как идентификатор, оно будет использовано буквально и целиком.

  • format:<format> — любая строка, принимаемая параметром --format команды git log. (См. раздел PRETTY FORMATS в git-log[1].)

Если --group указан несколько раз, коммиты учитываются для каждого значения (но, как и прежде, только один раз для каждого уникального значения в коммите). Например, git shortlog --group=author --group=trailer:co-authored-by учитывает и авторов, и соавторов.

-c
--committer

Это псевдоним для --group=committer.

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

Переносить строки вывода, ограничивая каждую строку значением width. Первая строка каждой записи имеет отступ в indent1 пробелов, а вторая и последующие строки — в indent2 пробелов. По умолчанию значения width, indent1 и indent2 равны 76, 6 и 9 соответственно.

Если ширина равна 0 (нулю), строки вывода получают отступ, но не переносятся.

<revision-range>

Показывать только коммиты из указанного диапазона ревизий. Если <revision-range> не указан, по умолчанию используется HEAD (то есть вся история, ведущая к текущему коммиту). origin..HEAD задаёт все коммиты, достижимые из текущего коммита (то есть HEAD), но не из origin. Полный список способов записи <revision-range> см. в разделе Specifying Ranges в gitrevisions[7].

[--] <path>...

Учитывать только коммиты, необходимые для объяснения того, как появились файлы, соответствующие указанным путям.

Если возникает неоднозначность, перед путями может потребоваться указать --, чтобы отделить их от параметров или диапазона ревизий.

Ограничение коммитов

Помимо указания диапазона коммитов, которые следует вывести, с помощью специальных обозначений, описанных в документации, можно применить дополнительные ограничения.

Как правило, чем больше параметров используется, тем сильнее ограничивается вывод (например, --since=<date1> ограничивает вывод коммитами, созданными после <date1>, а использование этого параметра вместе с --grep=<pattern> дополнительно ограничивает вывод коммитами, в сообщении журнала которых есть строка, соответствующая <pattern>), если не указано иное.

Обратите внимание, что эти параметры применяются до параметров сортировки и форматирования коммитов, таких как --reverse.

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

Ограничить вывод первыми <number> коммитами, которые должны быть показаны.

--max-count-oldest=<number>

Ограничить вывод последними <number> коммитами, которые должны быть показаны.

--skip=<number>

Пропустить <number> коммитов, прежде чем начать выводить информацию о коммитах.

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

Показать коммиты, созданные позже <date>. В особом случае today означает последнюю полночь.

--since-as-filter=<date>

Показать все коммиты, созданные позже <date>. Этот параметр просматривает все коммиты в диапазоне, а не останавливается на первом коммите, созданном раньше <date>.

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

Показать коммиты, созданные раньше <date>.

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

Ограничить вывод коммитами, в которых строки заголовка автора/коммиттера соответствуют регулярному выражению <pattern>. Если указано несколько параметров --author=<pattern>, выбираются коммиты, автор которых соответствует любому из <pattern> (аналогично для нескольких параметров --committer=<pattern>).

--grep-reflog=<pattern>

Ограничить вывод коммитами, записи reflog которых соответствуют регулярному выражению <pattern>. Если указано несколько параметров --grep-reflog, выбираются коммиты, сообщение reflog которых соответствует любому из заданных шаблонов. Использование этого параметра без параметра --walk-reflogs приводит к ошибке.

--grep=<pattern>

Ограничить вывод коммитами, сообщение журнала которых соответствует регулярному выражению <pattern>. Если указано несколько параметров --grep=<pattern>, выбираются коммиты, сообщение которых соответствует любому из <pattern> (см. также --all-match).

Если используется --notes, текст заметок сопоставляется так, как если бы он был частью сообщения журнала.

--all-match

Ограничить вывод коммитами, соответствующими всем заданным параметрам --grep, а не хотя бы одному из них.

--invert-grep

Ограничить вывод коммитами, сообщение журнала которых не соответствует регулярному выражению <pattern>, указанному с помощью --grep=<pattern>.

-i
--regexp-ignore-case

Сопоставлять шаблоны регулярных выражений, используемые для ограничения вывода, без учёта регистра.

--basic-regexp

Считать шаблоны ограничений базовыми регулярными выражениями; это поведение по умолчанию.

-E
--extended-regexp

Считать шаблоны ограничений расширенными регулярными выражениями, а не базовыми регулярными выражениями, используемыми по умолчанию.

-F
--fixed-strings

Считать шаблоны ограничений фиксированными строками (не интерпретировать шаблон как регулярное выражение).

-P
--perl-regexp

Считать шаблоны ограничений регулярными выражениями, совместимыми с Perl.

Поддержка этих типов регулярных выражений является необязательной зависимостью на этапе компиляции. Если Git был скомпилирован без их поддержки, указание этого параметра приведёт к аварийному завершению работы.

--remove-empty

Остановиться, если указанный путь исчезнет из дерева.

--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 — все коммиты слияния нескольких веток.

Параметры --no-min-parents и --no-max-parents сбрасывают эти ограничения (то есть снимают их). Эквивалентными формами являются --min-parents=0 (любой коммит имеет 0 или более родителей) и --max-parents=-1 (отрицательные числа обозначают отсутствие верхнего предела).

--first-parent

При поиске коммитов для включения следовать только за первым родительским коммитом при обнаружении коммита слияния. Этот параметр помогает лучше понять развитие конкретной тематической ветки: слияния в тематическую ветку обычно нужны лишь для периодической синхронизации с обновлённой вышестоящей веткой, а этот параметр позволяет игнорировать отдельные коммиты, добавленные в историю таким слиянием.

--exclude-first-parent-only

При поиске коммитов для исключения (с помощью ^) следовать только за первым родительским коммитом при обнаружении коммита слияния. Это можно использовать, чтобы найти набор изменений в тематической ветке с момента её отделения от удалённой ветки, учитывая, что произвольные слияния могут быть допустимыми изменениями тематической ветки.

--maximal-only

Ограничить вывод коммитами, которые недостижимы из любых других коммитов в диапазоне ревизий.

--not

Инвертирует значение префикса ^ (или его отсутствия) для всех последующих спецификаторов ревизий до следующего --not. Если этот параметр указан в командной строке перед --stdin, он не влияет на ревизии, переданные через stdin. И наоборот, если параметр передан через стандартный ввод, он не влияет на ревизии, переданные в командной строке.

--all

Считать, что все ссылки в refs/ вместе с HEAD указаны в командной строке как <commit>.

--branches[=<pattern>]

Считать, что все ссылки в refs/heads указаны в командной строке как <commit>. Если указан <pattern>, ограничить вывод ветками, соответствующими заданному шаблону оболочки. Если в <pattern> отсутствуют ?, * или [, в конец подразумеваемо добавляется /*.

--tags[=<pattern>]

Считать, что все ссылки в refs/tags указаны в командной строке как <commit>. Если указан <pattern>, ограничить вывод тегами, соответствующими заданному шаблону оболочки. Если в шаблоне отсутствуют ?, * или [, в конец подразумеваемо добавляется /*.

--remotes[=<pattern>]

Считать, что все ссылки в refs/remotes указаны в командной строке как <commit>. Если указан <pattern>, ограничить вывод ветками отслеживания удалённых репозиториев, соответствующими заданному шаблону оболочки. Если в шаблоне отсутствуют ?, * или [, в конец подразумеваемо добавляется /*.

--glob=<glob-pattern>

Считать, что все ссылки, соответствующие шаблону оболочки <glob-pattern>, указаны в командной строке как <commit>. Если начальный refs/ отсутствует, он добавляется автоматически. Если в шаблоне отсутствуют ?, * или [, в конец подразумеваемо добавляется /*.

--exclude=<glob-pattern>

Не включать ссылки, соответствующие <glob-pattern>, которые в противном случае учитывались бы следующим параметром --all, --branches, --tags, --remotes или --glob. При повторном использовании этого параметра шаблоны исключения накапливаются до следующего параметра --all, --branches, --tags, --remotes или --glob (другие параметры и аргументы не сбрасывают накопленные шаблоны).

При применении к --branches, --tags или --remotes шаблоны не должны начинаться с refs/heads, refs/tags или refs/remotes соответственно; при применении к --glob или --all они должны начинаться с refs/. Если нужен завершающий /*, его необходимо указать явно.

--exclude-hidden=(fetch|receive|uploadpack)

Не включать ссылки, которые были бы скрыты параметрами git-fetch, git-receive-pack или git-upload-pack; для этого проверяется соответствующая конфигурация fetch.hideRefs, receive.hideRefs или uploadpack.hideRefs вместе с transfer.hideRefs (см. git-config[1]). Этот параметр влияет на следующий параметр псевдоссылки --all или --glob и сбрасывается после их обработки.

--reflog

Считать, что все объекты, упомянутые в reflog, указаны в командной строке как <commit>.

--alternate-refs

Считать, что все объекты, упомянутые в качестве вершин ссылок альтернативных репозиториев, указаны в командной строке. Альтернативным является любой репозиторий, каталог объектов которого указан в objects/info/alternates. Набор включаемых объектов можно изменить с помощью core.alternateRefsCommand и других параметров. См. git-config[1].

--single-worktree

По умолчанию, если рабочих деревьев больше одного, следующие параметры проверяют все рабочие деревья (см. git-worktree[1]): --all, --reflog и --indexed-objects. Этот параметр заставляет их проверять только текущее рабочее дерево.

--ignore-missing

При обнаружении во входных данных недопустимого имени объекта считать, что ошибочные входные данные не были переданы.

--bisect

Считать, что ошибочная ссылка двоичного поиска refs/bisect/bad была указана, а за ней в командной строке следовали --not и корректные ссылки двоичного поиска refs/bisect/good-*.

--stdin

Помимо получения аргументов из командной строки, читать их также из стандартного ввода. Принимаются коммиты и псевдопараметры, например --all и --glob=. После обнаружения разделителя -- последующие входные данные обрабатываются как пути и используются для ограничения результата. Флаги, например --not, переданные через стандартный ввод, учитываются только для аргументов, переданных тем же способом, и не влияют на последующие аргументы командной строки.

--cherry-mark

Аналогично параметру --cherry-pick (см. ниже), но эквивалентные коммиты помечаются символом =, а не исключаются, а неэквивалентные — символом +.

--cherry-pick

Исключить коммиты, добавляющие те же изменения, что и другой коммит «на другой стороне», если набор коммитов ограничен симметричной разностью.

Например, если у вас есть две ветки, A и B, обычно все коммиты, присутствующие только в одной из них, перечисляют с помощью --left-right (см. пример ниже в описании параметра --left-right). Однако при этом выводятся коммиты, перенесённые выборочно из другой ветки (например, «3rd on b» может быть перенесён выборочно из ветки A). Этот параметр исключает такие пары коммитов из вывода.

--left-only
--right-only

Вывести только коммиты, находящиеся на соответствующей стороне симметричной разности, то есть только те, которые были бы помечены символом < или > соответственно при использовании --left-right.

Например, --cherry-pick --right-only A...B исключает из B коммиты, присутствующие в A или эквивалентные по исправлению коммиту из A. Иными словами, эта команда выводит коммиты + из git cherry A B. Точнее, --cherry-pick --right-only --no-merges выдаёт точный список.

--cherry

Синоним для --right-only --cherry-mark --no-merges; полезен для ограничения вывода коммитами с нашей стороны и пометки тех, которые были применены к другой стороне разветвлённой истории, символами git log --cherry upstream...mybranch, аналогично git cherry upstream mybranch.

-g
--walk-reflogs

Вместо обхода цепочки предков коммита обходить записи reflog от самой новой к более старым. При использовании этого параметра нельзя указать коммиты для исключения (то есть нельзя использовать обозначения ^<commit>, <commit1>..<commit2> и <commit1>...<commit2>).

Если используется формат --pretty, отличный от oneline и reference (по очевидным причинам), в вывод добавляются две строки с информацией из reflog. Обозначение reflog в выводе может иметь вид ref@{<Nth>} (где <Nth> — индекс записи в reflog в обратном хронологическом порядке) или ref@{<timestamp>} (с <timestamp> этой записи) — в зависимости от нескольких правил:

  1. Если начальная точка указана как ref@{<Nth>}, выводить индекс.

  2. Если начальная точка указана как ref@{now}, выводить отметку времени.

  3. Если не использовалось ни то ни другое, но в командной строке задан параметр --date, выводить отметку времени в формате, указанном параметром --date.

  4. В противном случае выводить индекс.

При использовании --pretty=oneline сообщение коммита дополняется этой информацией в той же строке. Этот параметр нельзя сочетать с --reverse. См. также git-reflog[1].

При использовании --pretty=reference эта информация не выводится.

--merge

Показать коммиты, затрагивающие конфликтующие пути в диапазоне HEAD...<other>, где <other> — первая существующая псевдоссылка из MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD или REBASE_HEAD. Работает только при наличии неслитых записей в индексе. Этот параметр можно использовать для показа релевантных коммитов при разрешении конфликтов трёхстороннего слияния.

--boundary

Выводить исключённые граничные коммиты. Перед граничными коммитами ставится префикс -.

Упрощение истории

Иногда вас интересуют только некоторые части истории, например коммиты, изменяющие определённый <path>. Однако у History Simplification есть две составляющие: одна — выбор коммитов, другая — способ его выполнения, поскольку существуют различные стратегии упрощения истории.

Следующие параметры выбирают коммиты для отображения:

<paths>

Выбираются коммиты, изменяющие указанные <paths>.

--simplify-by-decoration

Выбираются коммиты, на которые ссылается какая-либо ветка или тег.

Обратите внимание: для представления осмысленной истории могут отображаться дополнительные коммиты.

Следующие параметры влияют на способ упрощения:

Default mode

Упрощает историю до простейшей истории, объясняющей конечное состояние дерева. Она является простейшей, поскольку из неё удаляются некоторые боковые ветви, если конечный результат совпадает (то есть при слиянии ветвей с одинаковым содержимым).

--show-pulls

Включает все коммиты из режима по умолчанию, а также коммиты слияния, которые не являются TREESAME относительно первого родителя, но являются TREESAME относительно более позднего родителя. Этот режим полезен для отображения коммитов слияния, которые «впервые внесли» изменение в ветку.

--full-history

То же, что и режим по умолчанию, но некоторые части истории не удаляются.

--dense

Отображаются только выбранные коммиты, а также некоторые коммиты, необходимые для представления осмысленной истории.

--sparse

Отображаются все коммиты в упрощённой истории.

--simplify-merges

Дополнительный параметр для --full-history, удаляющий из результирующей истории некоторые ненужные слияния, поскольку в них нет выбранных коммитов, повлиявших на результат.

--ancestry-path[=<commit>]

Если задан диапазон коммитов для отображения (например, <commit1>..<commit2> или <commit2> ^<commit1>) и коммит <commit> из этого диапазона, отображаются только те коммиты диапазона, которые являются предками <commit>, потомками <commit> или самим <commit>. Если коммит не указан, в качестве <commit> используется <commit1> (исключённая часть диапазона). Параметр можно передавать несколько раз; в этом случае коммит включается, если он совпадает с любым из указанных коммитов либо является предком или потомком одного из них.

Далее следует более подробное объяснение.

Предположим, что в качестве <paths> указан foo. Будем называть коммиты, изменяющие foo, не-TREESAME, а остальные — TREESAME. (В diff, отфильтрованном по 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 объединяет строки в quux xyzzy. P является TREESAME относительно O, но не относительно E.

  • X — независимый корневой коммит, добавивший новый файл side, который был изменён в Y. Y является TREESAME относительно X. Его слияние Q добавило side в P, поэтому Q является TREESAME относительно P, но не относительно Y.

rev-list перемещается назад по истории, включая или исключая коммиты в зависимости от того, используются ли --full-history и/или переписывание родителей (посредством --parents или --children). Доступны следующие параметры.

Режим по умолчанию

Коммиты включаются, если они не являются TREESAME ни относительно одного из родителей (это можно изменить; см. ниже --sparse). Если коммит является слиянием и TREESAME относительно одного из родителей, переход выполняется только к этому родителю. (Даже если таких родителей несколько, переход выполняется только к одному из них.) В противном случае переход выполняется ко всем родителям.

В результате получаем:

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

Обратите внимание: правило перехода только к родителю TREESAME, если такой имеется, полностью исключило B из рассмотрения. C рассматривался через N, но является TREESAME. Корневые коммиты сравниваются с пустым деревом, поэтому I не-TREESAME.

Отношения родитель/потомок видны только с параметром --parents, но он не влияет на выбор коммитов в режиме по умолчанию, поэтому линии родства показаны.

--full-history без переписывания родителей

Этот режим отличается от режима по умолчанию одним: он всегда переходит ко всем родителям слияния, даже если коммит является TREESAME относительно одного из них. Даже если включённые коммиты есть в нескольких ветвях слияния, это не означает, что включается само слияние. В нашем примере получаем:

        I  A  B  N  D  O  P  Q

M исключён, поскольку он TREESAME относительно обоих родителей. Для E, C и B выполнялся обход, но только B был не-TREESAME, поэтому остальные не отображаются.

Обратите внимание: без переписывания родителей нельзя по-настоящему говорить об отношениях родитель/потомок между коммитами, поэтому они показаны несвязанными.

--full-history с переписыванием родителей

Обычные коммиты включаются, только если они не-TREESAME (это можно изменить; см. ниже --sparse).

Слияния всегда включаются. Однако их список родителей переписывается: для каждого родителя удаляются коммиты, которые сами не включены. В результате получаем:

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

Сравните с --full-history без переписывания выше. Обратите внимание, что E был удалён, поскольку он TREESAME, но список родителей P был переписан так, чтобы включить родителя I коммита E. То же самое произошло с C и N, а также с X, Y и Q.

Помимо описанных выше параметров, можно изменить, влияет ли TREESAME на включение:

--dense

Обходимые коммиты включаются, если они не являются TREESAME ни относительно одного из родителей.

--sparse

Включаются все обходимые коммиты.

Обратите внимание: без --full-history слияния всё равно упрощаются: если один из родителей TREESAME, переход выполняется только к нему, поэтому остальные ветви слияния не обходятся.

--simplify-merges

Сначала строится граф истории так же, как при использовании --full-history с переписыванием родителей (см. выше).

Затем каждый коммит C упрощается до его замены C' в конечной истории согласно следующим правилам:

  • Присвоить C' значение C.

  • Заменить каждого родителя P коммита C' его упрощённым вариантом P'. При этом удалить родителей, которые являются предками других родителей, или корневыми коммитами TREESAME относительно пустого дерева, а также убрать дубликаты; однако необходимо следить за тем, чтобы не удалить всех родителей, относительно которых коммит является TREESAME.

  • Если после такого переписывания родителей C' является корневым коммитом или коммитом слияния (имеет ноль или более одного родителя), граничным коммитом либо не-TREESAME, он остаётся. В противном случае он заменяется своим единственным родителем.

Лучше всего эффект этого правила виден при сравнении с --full-history с переписыванием родителей. Пример преобразуется в:

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

Обратите внимание на основные отличия N, P и Q от --full-history:

  • Из списка родителей N удалён I, поскольку он является предком другого родителя, M. При этом N остался, поскольку он не-TREESAME.

  • Из списка родителей P аналогичным образом удалён I. Затем P был удалён полностью, поскольку у него был один родитель и он является TREESAME.

  • В списке родителей Q коммит Y был упрощён до X. Затем X был удалён, поскольку это корневой коммит TREESAME. После этого Q был удалён полностью, поскольку у него был один родитель и он является 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, в смысле «что есть в M, чего не было в D». В этом примере результатом будут все коммиты, кроме A и B (и, разумеется, самого D).

Однако если мы хотим выяснить, какие коммиты в M затронуты ошибкой, внесённой в D, и нуждаются в исправлении, возможно, нам потребуется просмотреть только подмножество D..M, которое действительно является потомками D, исключив 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
                 \
              C---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 создан так, что содержимое file.txt в M проигнорировано и взято только содержимое file.txt в X. Поэтому R является TREESAME относительно X, но не относительно M. Наконец, естественный способ разрешить слияние и создать N — взять содержимое file.txt в R, поэтому N является TREESAME относительно R, но не относительно C. Коммиты слияния O и P являются TREESAME относительно своих первых родителей, но не относительно вторых родителей — соответственно 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 достижимы из их первых родителей. Эти рёбра удаляются, и коммиты выглядят как коммиты с одним родителем, являющиеся TREESAME относительно своего родителя. То же происходит с коммитом N, в результате чего история выглядит так:

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

В этом представлении видны все важные изменения в коммитах с одним родителем: A, B и X. Также видны тщательно разрешённое слияние M и не слишком тщательно разрешённое слияние R. Обычно этой информации достаточно, чтобы понять, почему коммиты A и B «исчезли» из истории в представлении по умолчанию. Однако у этого подхода есть несколько недостатков.

Первый недостаток — производительность. В отличие от всех предыдущих параметров, параметр --simplify-merges требует обхода всей истории коммитов, прежде чем будет возвращен хотя бы один результат. Поэтому этот параметр может быть неудобен для очень больших репозиториев.

Второй недостаток связан с аудитом. Когда над одним репозиторием работают многие участники, важно знать, какие коммиты слияния внесли изменение в важную ветку. Проблемное слияние R, показанное выше, скорее всего, не является коммитом слияния, использованным для слияния в важную ветку. Вместо этого для слияния R и X в важную ветку использовался коммит N. В сообщении этого коммита может быть указано, почему изменение X заменило изменения из A и B.

--show-pulls

Помимо коммитов, отображаемых в истории по умолчанию, показывает каждый коммит слияния, который не является TREESAME относительно первого родителя, но является TREESAME относительно более позднего родителя.

Если коммит слияния включён благодаря --show-pulls, считается, что слияние «подтянуло» изменение из другой ветки. При использовании --show-pulls в этом примере (без других параметров) полученный граф выглядит так:

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

Здесь коммиты слияния R и N включены, поскольку они подтянули коммиты X и R в основную ветку соответственно. Именно из-за этих слияний коммиты A и B не отображаются в истории по умолчанию.

Если использовать --show-pulls вместе с --simplify-merges, граф будет содержать всю необходимую информацию:

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

Обратите внимание: поскольку M достижим из R, ребро от N к M было удалено при упрощении. Однако N по-прежнему отображается в истории как важный коммит, поскольку он «подтянул» изменение R в основную ветку.

Параметр --simplify-by-decoration позволяет увидеть только общую топологию истории, опуская коммиты, на которые не ссылаются теги. Коммиты помечаются как не-TREESAME (то есть сохраняются после описанных выше правил упрощения истории), если (1) на них ссылаются теги или (2) они изменяют содержимое путей, указанных в командной строке. Все остальные коммиты помечаются как TREESAME (и могут быть удалены при упрощении).

Сопоставление авторов

См. gitmailmap[5].

Обратите внимание: если git shortlog выполняется вне репозитория (для обработки содержимого журнала из стандартного ввода), программа ищет файл .mailmap в текущем каталоге.

shortlog

© 2005–2026 Linus Torvalds and others
Licensed under the GNU General Public License version 2.
https://git-scm.com/docs/git-shortlog

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API