Русский ▾ Topics ▾ Latest version ▾ git-shortlog last updated in 2.54.0

НАЗВАНИЕ

git-shortlog - Сводка вывода git log

ОБЗОР

git shortlog [<параметры>] [<диапазон-редакций>] [[--] <путь>…​]
git log --pretty=short | git shortlog [<параметры>]

ОПИСАНИЕ

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

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

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

ПАРАМЕТРЫ

-n
--numbered

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

-s
--summary

Подавлять описание коммита и предоставлять только сводку количества коммитов.

-e
--email

Отображать email адрес каждого автора.

--format[=<format>]

Вместо темы коммита используйте другую информацию для описания каждого коммита. <формат> может быть любой строкой, принимаемой параметром --format команды git log, например * [%h] %s. (См. раздел "ФОРМАТЫ ВЫВОДА" в git-log[1].)

Каждый красиво напечатанный коммит будет перевёрстан перед показом.

--date=<формат>

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

--group=<тип>

Группировать коммиты на основе <тип>. Если параметр --group не указан, по умолчанию используется author. <тип> может быть одним из:

  • author, коммиты группируются по автору

  • committer, коммиты группируются по коммиттеру (то же, что и -c)

  • trailer:<поле>, <поле> интерпретируется как завершитель (trailer) сообщения коммита без учёта регистра (см. git-interpret-trailers[1]). Например, если ваш проект использует завершители Reviewed-by, вы можете увидеть, кто рецензировал, с помощью git shortlog -ns --group=trailer:reviewed-by.

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

    Shortlog попытается проанализировать каждое значение завершителя как идентичность имя <email>. В случае успеха применяется mailmap, и email опускается, если не указан параметр --email. Если значение не может быть проанализировано как идентичность, оно будет принято буквально и полностью.

  • format:<формат>, любая строка, принимаемая параметром --format команды git log. (См. раздел "ФОРМАТЫ ВЫВОДА" в git-log[1].)

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

-c
--committer

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

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

Выполняет перенос строк вывода, оборачивая каждую строку на ширина. Первая строка каждой записи имеет отступ в отступ1 пробелов, а вторая и последующие строки имеют отступ в отступ2 пробела. Значения ширина, отступ1 и отступ2 по умолчанию равны 76, 6 и 9 соответственно.

Если ширина равна 0 (нулю), то строки вывода имеют отступ без их переноса.

<диапазон-редакций>

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

[--] <путь>…​

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

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

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

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

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

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

-<число>
-n <число>
--max-count=<число>

Ограничить вывод <числом> коммитов.

--skip=<число>

Пропустить <число> коммитов перед началом показа вывода коммитов.

--since=<дата>
--after=<дата>

Показать коммиты новее <дата>.

--since-as-filter=<дата>

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

--until=<дата>
--before=<дата>

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

--author=<шаблон>
--committer=<шаблон>

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

--grep-reflog=<шаблон>

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

--grep=<шаблон>

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

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

--all-match

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

--invert-grep

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

-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=<число>
--max-parents=<число>
--no-min-parents
--no-max-parents

Показывать только коммиты, которые имеют по крайней мере (или не более) указанное количество родительских коммитов. В частности, --max-parents=1 — то же самое, что --no-merges, --min-parents=2 — то же самое, что --merges. --max-parents=0 даёт все корневые коммиты, а --min-parents=3 — все слияния octopus.

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

--first-parent

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

--exclude-first-parent-only

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

--maximal-only

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

--not

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

--all

Предполагать, как если бы все ссылки в refs/, вместе с HEAD, были перечислены в командной строке как <коммит>.

--branches[=<шаблон>]

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

--tags[=<шаблон>]

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

--remotes[=<шаблон>]

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

--glob=<шаблон-glob>

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

--exclude=<шаблон-glob>

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

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

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

Предполагать, как если бы все объекты, упомянутые в журналах ссылок (reflogs), были перечислены в командной строке как <коммит>.

--alternate-refs

Предполагать, как если бы все объекты, упомянутые как верхушки (tips) ссылок дополнительных репозиториев, были перечислены в командной строке. Дополнительный репозиторий — это любой репозиторий, чей каталог объектов указан в 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). Однако он показывает коммиты, которые были скопированы (cherry-picked) из другой ветки (например, «3rd on b» мог быть скопирован из ветки A). С этим параметром такие пары коммитов исключаются из вывода.

--left-only
--right-only

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

Например, --cherry-pick --right-only A...B опускает те коммиты из B, которые находятся в A или являются эквивалентными по изменению (patch-equivalent) коммиту в 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) от самых последних к более старым. При использовании этого параметра вы не можете указывать коммиты для исключения (то есть обозначения ^<коммит>, <коммит1>..<коммит2> и <коммит1>...<коммит2> не могут использоваться).

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

  1. Если начальная точка указана как ref@{<N-й>}, показывать формат индекса.

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

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

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

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

В режиме --pretty=reference эта информация вообще не будет отображаться.

--merge

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

--boundary

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

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

Иногда вас интересуют только части истории, например, коммиты, изменяющие конкретный <путь>. Но в «Упрощении истории» есть две части: одна — выбор коммитов, а другая — как это сделать, поскольку существует множество стратегий упрощения истории.

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

<пути>

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

--simplify-by-decoration

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

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

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

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

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

--show-pulls

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

--full-history

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

--dense

Показываются только выбранные коммиты плюс некоторые для осмысленности истории.

--sparse

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

--simplify-merges

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

--ancestry-path[=<коммит>]

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

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

Предположим, вы указали 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 для одного родителя, следовать только этому родителю. (Даже если есть несколько родителей 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 ниже).

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

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

Сравните с --full-history без перезаписи выше. Обратите внимание, что E был отсечён, потому что он является TREESAME, но список родителей P был переписан, чтобы содержать родителя EI. То же самое произошло с 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[=<коммит>]

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

В качестве примера рассмотрим следующую историю коммитов:

	    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=D вместо --ancestry-path, что означает то же самое при применении к диапазону 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 выше, вероятно, не является коммитом слияния, который использовался для слияния с важной веткой. Вместо этого слияние N использовалось для слияния R и X в важную ветку. Этот коммит может содержать в своём сообщении информацию о том, почему изменение X переопределило изменения из A и B.

--show-pulls

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

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

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

Здесь коммиты слияния R и N включены, потому что они извлекли (pulled) коммиты X и R в базовую ветку соответственно. Эти слияния являются причиной того, что коммиты A и B не отображаются в истории по умолчанию.

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

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

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

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

СОПОСТАВЛЕНИЕ АВТОРОВ

См. gitmailmap[5].

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

GIT

Является частью пакета git[1]