українська мова ▾ Topics ▾ Latest version ▾ git-shortlog last updated in 2.53.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. (Див. розділ "ГАРНІ ФОРМАТИ" у 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. (Див. розділ "ГАРНІ ФОРМАТИ" у git-log[1].)

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

    Shortlog спробує розібрати кожне значення трейлера як ідентифікатор name <email>. У разі успіху застосовується mailmap, а 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 відповідно.

Якщо значення параметра width дорівнює 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 відповідають регулярному виразу <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

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

--no-min-parents та --no-max-parents знову скидають ці обмеження (до нульового значення). Еквівалентними формами є --min-parents=0 (будь-який коміт має 0 або більше батьків) та --max-parents=-1 (відʼємні числа означають відсутність верхньої межі).

--first-parent

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

--exclude-first-parent-only

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

--not

Змінює значення префікса ^ (або його відсутності) на протилежне для всіх наступних специфікаторів версій, аж до наступного --not. Якщо цей параметр вказано в командному рядку перед параметром --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>, перелічені в командному рядку як <комміт>. Початковий 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). Однак він показує коміти, які були вибрані з іншої гілки (наприклад, «3-й в гілці 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 (з очевидних причин), це призводить до того, що вивід містить два додаткові рядки інформації, взятої з журналу змін (reflog). Позначення журналу змін у вивідних даних може відображатися як 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 як <paths>. Ми будемо називати коміти, що змінюють 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 нижче).

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

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