українська мова ▾ Topics ▾ Latest version ▾ git-shortlog last updated in 2.51.0

НАЗВА

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 у розділі "Форматування комітів" у git-log[1]). Корисно з --group=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.

  • format:<формат>, будь-який рядок, що приймається опцією --format команді git log. (Див. розділ "PRETTY FORMATS" у git-log[1].)

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

    Shortlog спробує розібрати кожне значення трейлера як ідентифікатор name <email>. У разі успіху застосовується карта пошти, а електронна адреса пропускається, якщо не вказано опцію --email. Якщо значення не може бути розібране як ідентифікатор, воно буде сприйнято буквально та повністю.

Якщо --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> див. у розділі "Визначення діапазонів" у gitrevisions[7].

[--] <path>…​

Розгляньте лише ті коміти, яких достатньо для пояснення того, як виникли файли, що відповідають зазначеним шляхам.

Шляхи можуть потребувати префікса --, щоб відокремити їх від опцій або діапазону версій, у разі виникнення плутанини.

Обмеження комітів

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

Використання більшої кількості опцій зазвичай ще більше обмежує вивід (наприклад, --since=<date1> обмежує коміти, новіші за <date1>, а використання з --grep=<pattern> ще більше обмежує коміти, повідомлення журналу яких містить рядок, що відповідає <pattern>), якщо не зазначено інше.

Зверніть увагу, що ці параметри застосовуються перед упорядкуванням комітів та параметрами форматування, такими як --reverse.

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

Обмежити вивід до <number> комітів.

--skip=<number>

Пропустити <number> комітів перед початком відображення виводу коміта.

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

Показати коміти, новіші за <date>.

--since-as-filter=<date>

Показати всі коміти, новіші за <date>. Це відвідує всі коміти в діапазоні, а не зупиняється на першому коміті, який старший за <date>.

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

Показати коміти, старші за <date>.

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

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

--grep-reflog=<pattern>

Обмежте вивід комітів тими, у яких записи reflog відповідають регулярному виразу <pattern>. Якщо --grep-reflog використовується більше одного шаблону, вибираються коміти, повідомлення reflog яких відповідає будь-якому з заданих шаблонів. Використання цієї опції є помилкою, якщо не використовується --walk-reflogs.

--grep=<pattern>

Обмежте вивід комітів тими, у яких повідомлення журналу відповідає регулярному виразу <шаблон>. Якщо є більше одного --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=<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.

--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/, разом з HEAD, перелічені в командному рядку як <commit>.

--branches[=<pattern>]

Зробіть вигляд, ніби всі посилання в refs/heads перелічені в командному рядку як <commit>. Якщо задано <pattern>, обмежте гілки тими, що відповідають заданому глобусу оболонки. Якщо <pattern> не містить ?, * або [, мається на увазі /* в кінці.

--tags[=<pattern>]

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

--remotes[=<pattern>]

Зробіть вигляд, що всі посилання в refs/remotes перелічені в командному рядку як <commit>. Якщо задано <pattern>, обмежте гілки віддаленого відстеження тими, що відповідають заданому глобусу оболонки. Якщо у шаблоні відсутні ?, * або [, мається на увазі /* в кінці.

--glob=<glob-pattern>

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

--exclude=<glob-pattern>

Не включайте посилання, що відповідають <glob-pattern>, які наступні --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, перелічені в командному рядку як <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

Замість того, щоб проходити ланцюжок походження комітів, перегляньте записи журналу походження від найновішого до найстаріших. Коли використовується ця опція, ви не можете вказати коміти для виключення (тобто нотації ^<commit>, <commit1>..<commit2> та <commit1>...<commit2> не можна використовувати).

Якщо формат --pretty відрізняється від oneline та reference (з очевидних причин), це призводить до того, що вивід містить два додаткові рядки інформації, взятої з журналу посилань. Позначення журналу посилань у вивідних даних може відображатися як ref@{<Nth>} (де <Nth> — це зворотний хронологічний індекс у журналі посилань) або як 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>. Але є дві частини «Спрощення історії», одна частина — це вибір комітів, а інша — як це зробити, оскільки існують різні стратегії спрощення історії.

Наступні опції вибирають коміти, які будуть показані:

<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>. Якщо коміт не вказано, використовуйте <commit1> (виключену частину діапазону) як <commit>. Можна передати кілька разів; якщо так, коміт включається, якщо він є будь-яким із заданих коммітів або якщо він є предком чи нащадком одного з них.

Далі наведено більш детальне пояснення.

Припустимо, ви вказали 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 об’єднує рядки в 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 нижче).

Злиття завжди включаються. Однак список батьківських елементів переписується: вздовж кожного батьківського елемента видаляються коміти, які самі не включені. Це призводить до

	  .-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’' є кореневим або злиттям-комітом (має нуль або >1 батьків), граничним комітом або !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=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 вище, ймовірно, не є тим комітом злиття, який було використано для злиття у важливу гілку. Натомість, для злиття 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 у поточному каталозі.

GIT

Частина набору git[1]