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

НАЗВА

git-rev-list - Перелічує об’єкти комітів у зворотному хронологічному порядку

СИНОПСИС

git rev-list [<options>] <commit>…​ [--] [<path>…​]

ОПИС

Виводить список комітів, до яких можна дістатися, перейшовши за посиланнями parent із вказаних комітів, але виключає коміти, до яких можна дістатися з тих, що позначені символом ^ перед номером. Стандартно вивід здійснюється у зворотному хронологічному порядку.

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

Таким чином, наступна команда:

$ git rev-list foo bar ^baz

означає «перелічити всі коміти, які доступні з foo або bar, але не з baz».

Спеціальне позначення "<commit1>..<commit2>" може використовуватися як скорочений запис для "^<commit1> <commit2>". Наприклад, будь-який з наступних варіантів може використовуватися як взаємозамінний:

$ git rev-list origin..HEAD
$ git rev-list HEAD ^origin

Ще одним спеціальним записом є "<commit1>...<commit2>", який корисний для злиття. Отриманий набір комітів є симетричною відмінністю між двома операндами. Наступні дві команди є еквівалентними:

$ git rev-list A B --not $(git merge-base --all A B)
$ git rev-list A...B

«rev-list» — це важлива команда Git, оскільки вона надає можливість створювати та переглядати графи предків комітів. З цієї причини вона має багато різних опцій, які дозволяють використовувати її такими різними командами, як «git bisect» та «git repack».

ОПЦІЇ

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

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

Використання додаткових опцій, як правило, ще більше обмежує вихідні дані (наприклад, --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>.

--max-age=<timestamp>
--min-age=<timestamp>

Обмежити вивід комітів заданим часовим діапазоном.

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

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

Якщо у вхідних даних виявлено недійсне імʼя обʼєкта, слід поводитися так, ніби таких даних не було надано.

--stdin

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

--quiet

Не виводити нічого у стандартний вивід. Ця форма призначена насамперед для того, щоб користувач міг перевірити код завершення та визначити, чи всі об’єкти діапазону пов’язані між собою (чи ні). Це швидше, ніж перенаправлення stdout у /dev/null, оскільки вивід не потребує форматування.

--disk-usage
--disk-usage=human

Придушити звичайний вивід; натомість вивести суму байтів, використаних для зберігання на диску вибраними комітами або об’єктами. Це еквівалентно перенаправленню виводу в команду git cat-file --batch-check='%(objectsize:disk), за винятком того, що працює набагато швидше (особливо з опцією --use-bitmap-index). Дивіться розділ CAVEATS у git-cat-file[1] щодо обмежень того, що означає «зберігання на диску». З опціональним значенням human розмір зберігання на диску показується у вигляді зрозумілого для людини рядка (наприклад, 12,24 Кіб, 3,50 Міб).

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

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

--use-bitmap-index

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

--progress=<header>

Показувати звіти про хід виконання в stderr під час розгляду обʼєктів. Текст <header> буде виведено з кожним оновленням прогресу.

-z

Замість розділення символами нового рядка, кожен виведений обʼєкт та супутні йому метадані розділяються за допомогою NUL-байтів. Вивід виводиться у такому вигляді:

<OID> NUL [<token>=<value> NUL]...

Додаткові метадані обʼєкта, такі як шляхи до обʼєктів або обʼєкти-межі, виводяться у форматі <token>=<value>. Значення токенів виводяться без змін, без будь-якого кодування чи обрізання. Запис OID ніколи не містить символу =, тому він використовується для позначення початку нового запису об’єкта. Приклади:

<OID> NUL
<OID> NUL path=<path> NUL
<OID> NUL boundary=yes NUL
<OID> NUL missing=yes NUL [<token>=<value> NUL]...

Цей режим сумісний лише з параметрами виводу --objects, --boundary та --missing.

Спрощення історії

Іноді вас цікавлять лише частини історії, наприклад, коміти, що змінюють певний <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 (підлягають видаленню за допомогою спрощення).

Помічники з бісекції

--bisect

Обмежте вихідні дані одним об’єктом коміту, який знаходиться приблизно посередині між включеними та виключеними комітами. Зверніть увагу, що посилання на поганий результат бісекції refs/bisect/bad додається до включених комітів (якщо воно існує), а посилання на хороший результат бісекції refs/bisect/good-* додаються до виключених комітів (якщо вони існують). Отже, припустимо, що в теці refs/bisect/ немає посилань, якщо

	$ git rev-list --bisect foo ^bar ^baz

виводить «середню точку», вивід двох команд

	$ git rev-list foo ^midpoint
	$ git rev-list midpoint ^bar ^baz

матиме приблизно таку ж довжину. Таким чином, пошук зміни, яка спричиняє регресію, зводиться до бінарного пошуку: потрібно послідовно генерувати та перевіряти нові «середні точки», доки ланцюжок комітів не стане довжиною в один коміт.

--bisect-vars

Обчислює те саме, що й --bisect, за винятком того, що посилання в refs/bisect/ не використовуються, і за винятком того, що виводить текст, готовий до обробки оболонкою. Ці рядки присвоїть назву середньої ревізії змінній bisect_rev, а очікувану кількість комітів, які будуть перевірені після перевірки bisect_rev, змінній bisect_nr, очікувану кількість комітів, які будуть перевірені, якщо bisect_rev виявиться хорошим, bisect_good, очікувану кількість комітів, які будуть перевірені, якщо bisect_rev виявиться поганим, bisect_bad, та кількість комітів, які ми зараз ділимо, bisect_all.

--bisect-all

Виводить усі обʼєкти комітів між включеними та виключеними комітами, упорядковані за їхньою відстанню до включених та виключених комітів. Посилання в refs/bisect/ не використовуються. Найдальше від них відображається першим. (Це єдине, що відображається за допомогою --bisect.)

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

Цю опцію можна використовувати разом з --bisect-vars, у цьому випадку після всіх відсортованих обʼєктів комітів буде той самий текст, як якби --bisect-vars використовувався окремо.

Порядок комітів

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

--date-order

Не показувати батьківських обʼєктів, поки не будуть показані всі дочірні обʼєкти, але в іншому випадку показувати коміти в порядку часових відбитків комітів.

--author-date-order

Не показувати батьківських обʼєктів, доки не будуть показані всі дочірні обʼєкти, але в іншому випадку показувати коміти впорядковані за часовим відбитком автора.

--topo-order

Не показувати батьківських обʼєктів, поки не будуть показані всі їхні дочірні обʼєкти, та уникати показу комітів у кількох переплетених рядках історії.

Наприклад, у такій історії комітів:

    ---1----2----4----7
	\	       \
	 3----5----6----8---

де числа позначають порядок часових відбитків комітів, git rev-list та інші з --date-order показують коміти в порядку часових відбитків: 8 7 6 5 4 3 2 1.

З --topo-order вони б показали 8 6 5 3 7 4 2 1 (або 8 7 4 2 6 5 3 1); деякі старіші коміти показуються перед новішими, щоб уникнути показу комітів з двох паралельних треків розробки разом.

--reverse

Вивести вибрані коміти для відображення (див. розділ «Обмеження комітів» вище) у зворотному порядку. Не можна поєднувати з --walk-reflogs.

Обхід обʼєктів

Ці опції здебільшого призначені для пакування репозиторіїв Git.

--objects

Вивести ідентифікатори обʼєктів будь-якого обʼєкта, на який посилаються перелічені коміти. --objects foo ^bar таким чином означає «надіслати мені всі ідентифікатори обʼєктів, які мені потрібно завантажити, якщо в мене є об’єкт коміту bar, але немає foo». Див. також --object-names нижче.

--in-commit-order

Вивести ідентифікатори дерев та блобів у порядку комітів. Ідентифікатори дерев та блобів виводяться після першого посилання на них у коміті.

--objects-edge

Подібно до --objects, але також виводить ідентифікатори виключених комітів з префіксом "-". Використовується git-pack-objects[1] для створення «тонкого» пакунка, який записує обʼєкти у дельта-форматі на основі об’єктів, що містяться у цих виключених комітах, з метою зменшення мережевого трафіку.

--objects-edge-aggressive

Подібно до --objects-edge, але намагається знайти виключені коміти ціною збільшення часу. Використовується замість --objects-edge для створення «тонких» пакунків для поверхневих репозиторіїв.

--indexed-objects

Вважати, ніби всі дерева та об’єкти, які використовує індекс, перелічені в командному рядку. Зверніть увагу, що, ймовірно, вам також знадобиться опція --objects.

--unpacked

Корисно лише з --objects; виводить ідентифікатори обʼєктів, які не входять до пакунків.

--object-names

Корисно лише з --objects; виводить назви знайдених ідентифікаторів обʼєктів. Це стандартна поведінка. Зверніть увагу, що "імʼя" кожного обʼєкта неоднозначне і здебільшого призначене як підказка для пакування обʼєктів. Зокрема: не розрізняється назва тегів, дерев і блобів; назви шляхів можна змінювати, щоб видалити символи нового рядка; і якщо обʼєкт з’являється кілька разів з різними назвами, відображається лише одна назва.

--no-object-names

Корисно лише з --objects; не виводить назви знайдених ідентифікаторів обʼєктів. Це інвертує --object-names. Цей прапорець дозволяє легше розбирати вивід за допомогою команд, таких як git-cat-file[1].

--filter=<filter-spec>

Корисно лише з одним із --objects*; оминає обʼєкти (зазвичай блоби) зі списку друкованих обʼєктів. <специфікація-фільтра> може бути одним із наступних:

Форма --filter=blob:none пропускає всі блоби.

Форма --filter=blob:limit=<n>[kmg] пропускає блоби розміром щонайменше <n> байтів або одиниць. <n> може дорівнювати нулю. Суфікси k, m та g можна використовувати для найменування одиниць у KiB, MiB або GiB. Наприклад, blob:limit=1k те саме, що й blob:limit=1024.

Форма --filter=object:type=(tag|commit|tree|blob) пропускає всі обʼєкти, які не належать до запитуваного типу. Зверніть увагу, що явно задані обʼєкти ігнорують фільтри та завжди виводяться, якщо також не вказано --filter-provided-objects.

Форма --filter=sparse:oid=<blob-ish> використовує специфікацію вибіркового перемикання що міститься в блобі (або блоб-виразі) <blob-ish>, щоб пропустити блоби, які не потрібні для вибіркового перемикання на запитуваних посиланнях.

Форма --filter=tree:<depth> пропускає всі блоби та дерева, глибина яких від кореневого дерева дорівнює >= <depth> (мінімальна глибина, якщо обʼєкт розташований на кількох рівнях у пройдених комітах). <depth>=0 не включатиме жодних дерев або блобів, якщо вони явно не включені в командному рядку (або стандартному вводі, коли використовується --stdin). <depth>=1 включатиме лише дерево та блоби, на які безпосередньо посилається коміт, який досяжний з <commit> або явно заданого обʼєкта. <depth>=2 подібна до <depth>=1, але також включає дерева та блоби, на один рівень віддалення від явно заданого коміту або дерева.

Зверніть увагу, що форму --filter=sparse:path=<шлях>, яка хоче читати з довільного шляху у файловій системі, було видалено з міркувань безпеки.

Для обʼєднання фільтрів можна вказати кілька прапорців --filter=. Включаються лише обʼєкти, які приймаються кожним фільтром.

Форму --filter=combine:<filter1>+<filter2>+...<filterN> також можна використовувати для обʼєднання кількох фільтрів, але це складніше, ніж просто повторювати прапорець --filter, і зазвичай це не потрібно. Фільтри обʼєднуються за допомогою +, а окремі фільтри мають %-кодування (тобто URL-кодування). Окрім символів + та %, наступні символи зарезервовані та також мають бути закодовані: ~!@#$^&*()[]{}\;",<>?'` а також усі символи з кодом ASCII <= 0x20, включаючи пробіл та символ нового рядка.

Також можна закодувати інші довільні символи. Наприклад, combine:tree:3+blob:none та combine:tree%3A3+blob%3Anone є еквівалентними.

--no-filter

Вимикає будь-який попередній аргумент --filter=.

--filter-provided-objects

Фільтрувати список явно заданих обʼєктів, які в іншому випадку завжди друкувалися б, навіть якби вони не відповідали жодному з фільтрів. Корисно лише з --filter=.

--filter-print-omitted

Корисно лише з --filter=; виводить список обʼєктів, пропущених фільтром. Ідентифікатори обʼєктів починаються з символу «~».

--missing=<missing-action>

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

Параметр --missing=error вказує rev-list зупинитися з помилкою у разі виявлення відсутнього об’єкта. Це стандартна поведінка.

Форма --missing=allow-any дозволить продовжити обхід обʼєкта, якщо буде виявлено відсутній обʼєкт. Відсутні обʼєкти будуть непомітно пропущені з результатів.

Форма --missing=allow-promisor подібна до allow-any, але дозволить продовження обходу обʼєктів лише для ОЧІКУВАНИХ відсутніх обʼєктів promisor. Неочікувано відсутні обʼєкти викличуть помилку.

Форма --missing=print подібна до allow-any, але також виведе список відсутніх обʼєктів. Ідентифікатори об’єктів починаються з символу “?”.

Форма --missing=print-info подібна до print, але також виведе додаткову інформацію про відсутній обʼєкт, виведену з обʼєкта, що його містить. Вся інформація виводиться в одному рядку з ідентифікатором відсутнього обʼєкта у формі: ?<oid> [<токен>=<значення>].... Пари <токен>=<значення>, що містять додаткову інформацію, відокремлюються одна від одної за допомогою SP. Значення кодується специфічним для токена способом, але SP або LF, що містяться в значенні, завжди мають бути представлені таким чином, щоб отримане закодоване значення не мало жодного з цих двох проблемних байтів. Кожен <токен>=<значення> може бути одним із наступних:

  • Параметр path=<path> вказує шлях до відсутнього об’єкта, визначений на основі об’єкта, що його містить. Шлях, який містить символ SP або спеціальні символи, за потреби береться в подвійні лапки у стилі мови C.

  • type=<тип> показує тип відсутнього обʼєкта, визначений на основі обʼєкта, який його містить.

Якщо деякі вершини, передані під час обходу, відсутні, вони також вважатимуться відсутніми, і обхід їх проігнорує. Однак якщо нам не вдасться отримати їхній ідентифікатор об’єкта, буде згенеровано помилку.

--exclude-promisor-objects

(Тільки для внутрішнього використання.) Обхід об’єктів-попередніх фільтрів на межі промісора. Ця опція використовується разом із частковим клонуванням. Вона діє сильніше, ніж --missing=allow-promisor, оскільки обмежує обхід, а не просто приховує помилки про відсутні об’єкти.

--no-walk[=(sorted|unsorted)]

Показувати лише задані коміти, але не проходити через їхніх предків. Не має ефекту, якщо вказано діапазон. Якщо вказано аргумент unsorted, коміти відображаються в порядку, в якому вони були введені в командному рядку. В іншому випадку (якщо sorted або аргумент не вказано), коміти відображаються у зворотному хронологічному порядку за часом коміту. Не можна поєднувати з --graph.

--do-walk

Замінює попередній --no-walk.

Форматування комітів

Використовуючи ці опції, git-rev-list[1] працюватиме подібно до більш спеціалізованої родини інструментів для ведення журналу комітів: git-log[1], git-show[1], і git-whatchanged[1].

--pretty[=<format>]
--format=<format>

Вивести вміст журналів комітів у заданому форматі, де <format> може бути одним із oneline, short, medium, full, fuller, reference, email, raw, format:<string> та tformat:<string>. Коли <format> не є жодним із перерахованих вище та містить %<placeholder>, це діє так, ніби було задано --pretty=tformat:<format>.

Див. розділ «ГАРНІ ФОРМАТИ» для отримання додаткової інформації щодо кожного формату. Якщо частину =<format> пропустити, зазвичай використовується значення medium.

Note
Ви можете вказати стандартний гарний формат у конфігурації репозиторію (див. git-config[1]).
--abbrev-commit

Замість повного 40-байтового шістнадцяткового імені обʼєкта коміту, показати префікс, який однозначно ідентифікує об’єкт. Для визначення мінімальної довжини префікса можна використати опцію --abbrev=<n> (яка також змінює вивід diff, якщо він відображається).

Це має зробити опцію --pretty=oneline набагато зручнішою для читання тим, хто користується терміналами з довжиною рядка 80 символів.

--no-abbrev-commit

Показувати повну 40-байтову шістнадцяткову назву обʼєкта коміту. Ця опція нівелює дію опції --abbrev-commit, незалежно від того, чи вказано її явно, чи вона випливає з інших опцій, таких як --oneline. Вона також замінює значення змінної log.abbrevCommit.

--oneline

Це скорочена форма одночасного використання опцій --pretty=oneline --abbrev-commit.

--encoding=<encoding>

Обʼєкти коміту зберігають кодування символів, яке використовується для повідомлення журналу, у своєму заголовку кодування; цю опцію можна використовувати, щоб вказати команді перекодувати повідомлення журналу коміту у кодування, якому віддає перевагу користувач. Для команд, що не стосуються plumbing, стандартним значенням є UTF-8. Зверніть увагу, що якщо об’єкт заявляє, що він кодований у X, і ми виводимо у X, ми виведемо об’єкт дослівно; це означає, що недійсні послідовності в оригінальному коміті можуть бути скопійовані у вивід. Аналогічно, якщо iconv(3) не зможе перекодувати коміт, ми просто виведемо оригінальний об’єкт дослівно.

--expand-tabs=<n>
--expand-tabs
--no-expand-tabs

Перед показом у вихідних даних виконати розширення табуляції (замінити кожен символ табуляції на кількість пробілів, достатню для заповнення до наступного стовпця екрана, який є кратним <n>) у повідомленні журналу. --expand-tabs є скороченим варіантом --expand-tabs=8, а --no-expand-tabs — скороченим варіантом --expand-tabs=0, що вимикає розширення табуляції.

Зазвичай символи табуляції розгортаються у гарному форматі, який робить відступ у повідомленні журналу у 4 пробіли (тобто medium — це стандартний варіант, full та fuller).

--show-signature

Перевірити дійсність підписаного об’єкта коміту, передавши підпис у команду gpg --verify, та показати результат.

--relative-date

Синонім до --date=relative.

--date=<format>

Діє лише для дат, показаних у форматі, зрозумілому для людини, наприклад, при використанні --pretty. Змінна конфігурації log.date встановлює стандартне значення для опції --date команди log. Зазвичай дати показуються в оригінальному часовому поясі (або комітера, або автора). Якщо до формату додається -local (наприклад, iso-local), замість цього використовується локальний часовий пояс користувача.

--date=relative показує дати відносно поточного часу, наприклад, “2 години тому”. Опція -local не має жодного ефекту для --date=relative.

--date=local є псевдонімом для --date=default-local.

--date=iso (або --date=iso8601) показує часові відбитки у форматі, подібному до ISO 8601. Відмінності від суворого формату ISO 8601:

  • пробіл замість роздільника дати/часу T

  • пробіл між часом і часовим поясом

  • без двокрапки між годинами та хвилинами часового поясу

--date=iso-strict (або --date=iso8601-strict) показує часові відбитки у суворому форматі ISO 8601.

--date=rfc (або --date=rfc2822) показує часові відбитки у форматі RFC 2822, які часто зустрічаються в повідомленнях е-пошти.

--date=short показує лише дату, але не час, у форматі РРРР-ММ-ДД.

--date=raw показує дату в секундах з епохи (1970-01-01 00:00:00 UTC), після чого йде пробіл, а потім часовий пояс як зміщення відносно UTC (+ або - з чотирма цифрами; перші дві — години, а другі дві — хвилини). Тобто, ніби позначка часу була відформатована за допомогою strftime("%s %z")). Зверніть увагу, що опція -local не впливає на значення seconds-since-epoch (яке завжди вимірюється в UTC), але змінює супутнє значення часового поясу.

--date=human показує часовий пояс, якщо часовий пояс не відповідає поточному часовому поясу, і не виводить повну дату, якщо вона збігається (тобто пропускає вивід року для дат, які є "цього року", але також пропускає всю дату, якщо вона припадає на останні кілька днів, і ми можемо просто сказати, який це був день тижня). Для старіших дат година та хвилина також пропускаються.

--date=unix показує дату як часову позначку епохи Unix (секунди з 1970 року). Як і у випадку з --raw, це завжди в UTC, тому -local не має жодного ефекту.

--date=format:<format> передає <format> до вашої системної strftime, за винятком %s, %z та %Z, які обробляються внутрішньо. Використовуйте --date=format:%c, щоб показати дату у форматі, що відповідає бажаному формату вашої системної локалізації. Повний список заповнювачів формату дивіться в посібнику strftime(3). Під час використання -local правильний синтаксис — --date=format-local:<format>.

--date=default  — це стандартний формат, який базується на виводі ctime(3). Він показує один рядок із трилітерним днем тижня, трилітерним місяцем, днем місяця, годинами-хвилинами-секундами у форматі "ГГ:ХХ:СС", далі 4-значний рік та інформація про часовий пояс, якщо не використовується місцевий часовий пояс, наприклад, Thu Jan 1 00:00:00 1970 +0000.

--header

Вивести вміст коміту у форматі RAW; кожен запис розділяється символом NUL.

--no-commit-header

Приховувати рядок заголовка, що містить "commit" та ідентифікатор обʼєкта, що друкується перед зазначеним форматом. Це не впливає на вбудовані формати; впливають лише на власні формати користувачів.

--commit-header

Перезаписує попередній --no-commit-header.

--parents

Також виводить батьківські елементи коміту (у форматі "commit parent…​"). Також вмикає перезапис батьківських елементів, див. «Спрощення історії» вище.

--children

Також вивести дочірні елементи коміту (у формі "commit child…​"). Також вмикає перезапис батьківських елементів, див. «Спрощення історії» вище.

--timestamp

Виводить необроблений часовий відбиток коміту.

--left-right

Позначає, з якої сторони симетричної різниці досяжний коміт. Коміти з лівого боку мають префікс <, а з правого - >. У поєднанні з --boundary ці коміти мають префікс -.

Наприклад, якщо у вас така топологія:

	     y---b---b  branch B
	    / \ /
	   /   .
	  /   / \
	 o---x---a---a  branch A

ви отримаєте такий результат:

	$ git rev-list --left-right --boundary --pretty=oneline A...B

	>bbbbbbb... 3rd on b
	>bbbbbbb... 2nd on b
	<aaaaaaa... 3rd on a
	<aaaaaaa... 2nd on a
	-yyyyyyy... 1st on b
	-xxxxxxx... 1st on a
--graph

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

Дозволяє переписування батьківських елементів, див. розділ «Спрощення історії» вище.

Означає використання опції --topo-order, але також можна вказати опцію --date-order.

--show-linear-break[=<barrier>]

Коли --graph не використовується, усі гілки історії згладжуються, що може ускладнити визначення того, що два послідовні коміти не належать до лінійної гілки. У такому випадку ця опція встановлює барʼєр між ними. Якщо вказано <barrier>, буде показано саме цей рядок, а не стандартний рядок.

--count

Виводить число, яке вказує, скільки комітів було б перераховано, та приховує весь інший вивід. При використанні разом з --left-right, натомість покаже кількість лівих та правих комітів, розділених табуляцією. При використанні разом з --cherry-mark, пропустить еквівалентні коміти з цих підрахунків та покаже кількість еквівалентних комітів, розділених табуляцією.

ГАРНІ ФОРМАТИ

Якщо коміт є злиттям, і якщо pretty-format не є oneline, email або raw, перед рядком Author: вставляється додатковий рядок. Цей рядок починається з "Merge:", і хеші батьківських комітів друкуються, розділені пробілами. Зверніть увагу, що перелічені коміти не обовʼязково є списком "прямих" батьківських комітів, якщо ви обмежили свій перегляд історії: наприклад, якщо вас цікавлять лише зміни, повʼязані з певною текою або файлом.

Існує кілька вбудованих форматів, і ви можете визначити додаткові формати, встановивши для параметра конфігурації pretty.<name> іншу назву формату або рядок format:, як описано нижче (див. git-config[1]). Ось детальна інформація про вбудовані формати:

  • oneline

    <hash> <title-line>

    Ця конструкція розроблена так, щоб бути якомога компактнішою.

  • short

    commit <hash>
    Author: <author>
    <title-line>
  • medium

    commit <hash>
    Author: <author>
    Date:   <author-date>
    <title-line>
    <повне-повідомлення-коміту>
  • full

    commit <hash>
    Author: <author>
    Commit: <committer>
    <title-line>
    <повне-повідомлення-коміту>
  • fuller

    commit <hash>
    Author:     <author>
    AuthorDate: <author-date>
    Commit:     <committer>
    CommitDate: <committer-date>
    <title-line>
    <повне-повідомлення-коміту>
  • reference

    <abbrev-hash> (<title-line>, <short-author-date>)

    Цей формат використовується для посилання на інший коміт у повідомленні коміту та є таким самим, як --pretty='format:%C(auto)%h (%s, %ad). Зазвичай дата форматується за допомогою --date=short, якщо явно не вказано інший параметр --date. Як і у випадку з будь-яким format: з заповнювачами формату, його вивід не залежить від інших параметрів, таких як --decorate та --walk-reflogs.

  • email

    From <hash> <date>
    From: <author>
    Date: <author-date>
    Subject: [PATCH] <title-line>
    <повне-повідомлення-коміту>
  • mboxrd

    Як і email, але рядки в повідомленні коміту, що починаються з "From" (перед якими стоїть нуль або більше символів ">"), відділяються за допомогою ">", щоб їх не плутали з початком нового коміту.

  • raw

    Формат raw показує весь коміт точно так, як він збережений в обʼєкті коміту. Примітно, що хеші відображаються повністю, незалежно від того, чи використовується --abbrev чи --no-abbrev, а інформація про батьків показує справжні батьківські коміти, без урахування graft або спрощення історії. Зауважте, що цей формат впливає на спосіб відображення комітів, але не на спосіб відображення diff, наприклад, за допомогою git log --raw. Щоб отримати повні назви обʼєктів у форматі raw diff, використовуйте --no-abbrev.

  • format:<рядок-формату>

    Формат format:<рядок-формату> дозволяє вказати, яку інформацію ви хочете відобразити. Він працює приблизно так само, як формат printf, але з одним істотним винятком: для введення нового рядка використовується %n, а не \n.

    Наприклад, «format:"Автором %h був %an, %ar%nНазва була >>%s<<%n"» виведе щось на кшталт цього:

    Автором fe6e0ee був Junio C Hamano, 23 години тому
    Назва була >>t4119: тест автообчислення -p<n> для традиційного введення різниці.<<

    Заповнювачі:

    • Заповнювачі, які розгортаються в один символ:

      %n

      символ нового рядка, перенос рядка

      %%

      символ %

      %x00

      %x, за яким йдуть дві шістнадцяткові цифри, замінюється на байт, що відповідає значенню цих цифр (далі в цьому документі ми будемо називати це «літеральним кодом форматування»).

    • Заповнювачі, що впливають на форматування наступних заповнювачів:

      %Cred

      змінити колір на червоний

      %Cgreen

      змінити колір на зелений

      %Cblue

      змінити колір на синій

      %Creset

      скинути колір на стандартний

      %C(<spec>)

      специфікація кольорів, як описано в розділі «Значення» розділу «ФАЙЛ КОНФІГУРАЦІЇ» на сторінці git-config[1]. Стандартно кольори відображаються лише тоді, коли вони ввімкнені для виводу журналу (за допомогою color.diff, color.ui або --color, з урахуванням налаштувань auto першого з них, якщо ми працюємо в терміналі). %C(auto,<spec>) приймається як історичний синонім стандартного значення (наприклад, %C(auto,red)). Вказання %C(always,<spec>) призведе до відображення кольорів навіть тоді, коли кольори інакше не ввімкнені (хоча варто розглянути можливість використання --color=always для ввімкнення кольорів для всього виводу, включаючи цей формат та все інше, що git може підфарбовувати) auto самостійно (тобто %C(auto)) увімкне автоматичне підфарбовування для наступних заповнювачів, доки колір не буде змінено знову.

      %m

      лівий (<), правий (>) або граничний (-) знак

      %w([<w>[,<i1>[,<i2>]]])

      перемикання перенесення рядків, як-от опція -w у git-shortlog[1].

      %<(<n>[,(trunc|ltrunc|mtrunc)])

      зробити так, щоб наступний заповнювач займав щонайменше N стовпців, додаючи пробіли праворуч, якщо це необхідно. За бажанням обрізати (за допомогою багатокрапки ..) зліва (ltrunc) ..ft, посередині (mtrunc) mi..le або в кінці (trunc) rig.., якщо вихідні дані довші за <n> стовпців. Примітка 1: обрізання працює правильно лише для <n> >= 2. Примітка 2: пробіли навколо значень <n> та <m> (див. нижче) є необов’язковими. Примітка 3: Емодзі та інші широкі символи займатимуть дві колонки, що може призвести до виходу за межі колонок. Примітка 4: декомпоновані знаки комбінування символів можуть бути неправильно розміщені на межі заповнення.

      %<|(<m> )

      зробити так, щоб наступний заповнювач займав простір щонайменше до <m>-го стовпця екрана, додаючи пробіли з правого боку, якщо це необхідно. Використовуйте від’ємні значення <m> для позицій стовпців, відрахованих від правого краю вікна терміналу.

      %>(<n>)
      %>|(<m>)

      подібно до %<(<n>), %<|(<m>) відповідно, але з пробілами зліва

      %>>(<n>)
      %>>|(<m>)

      подібно до %>(<n>), %>|(<m>) відповідно, за винятком того, що якщо наступний заповнювач займає більше пробілів, ніж задано, і ліворуч від нього є пробіли, використовуються ці пробіли

      %><(<n>)
      %><|(<m>)

      подібно до %<(<n>), %<|(<m>) відповідно, але з відступами з обох боків (тобто текст вирівнюється по центру)

    • Заповнювачі, які замінюються інформацією, отриманою з коміту:

      %H

      хеш коміту

      %h

      скорочений хеш коміту

      %T

      хеш дерева

      %t

      скорочений хеш дерева

      %P

      батьківські хеші

      %p

      скорочені батьківські хеші

      %an

      імʼя автора

      %aN

      імʼя автора (відповідно до .mailmap, див. git-shortlog[1] або git-blame[1])

      %ae

      електронна пошта автора

      %aE

      електронна пошта автора (відповідно до .mailmap, див. git-shortlog[1] або git-blame[1])

      %al

      локальна частина електронної пошти автора (частина перед знаком @)

      %aL

      локальна частина електронної пошти автора (див. %al) відповідно до .mailmap, див. git-shortlog[1] або git-blame[1])

      %ad

      дата автора (формат враховує опцію --date=)

      %aD

      дата автора, формат RFC2822

      %ar

      дата автора, відносна

      %at

      дата автора, позначка часу UNIX

      %ai

      дата автора, формат подібний до ISO 8601

      %aI

      дата автора, формат ISO 8601 (суворе дотримання формату)

      %as

      дата автора, короткий формат (РРРР-ММ-ДД)

      %ah

      дата автора, у форматі, зрозумілому для людини (наприклад, як опція --date=human у git-rev-list[1])

      %cn

      імʼя комітера

      %cN

      імʼя комітера (відповідно до .mailmap, див. git-shortlog[1] або git-blame[1])

      %ce

      електронна пошта комітера

      %cE

      електронна пошта комітера (відповідно до .mailmap, див. git-shortlog[1] або git-blame[1])

      %cl

      локальна частина електронної пошти комітера (частина перед знаком @)

      %cL

      локальна частина пошти комітера (див. %cl) відповідно до .mailmap, див. git-shortlog[1] або git-blame[1])

      %cd

      дата комітера (формат враховує опцію --date=)

      %cD

      дата комітера, формат RFC2822

      %cr

      дата комітера, відносна

      %ct

      дата комітера, часовий відбиток UNIX

      %ci

      дата комітера, формат подібний до ISO 8601

      %cI

      дата комітера, суворий формат ISO 8601

      %cs

      дата створення комітора, короткий формат (РРРР-ММ-ДД)

      %ch

      дата комітера, людський стиль (як опція --date=human у git-rev-list[1])

      %d

      назви посилань, як-от опція --decorate для git-log[1]

      %D

      імена посилань без дужок "(", ")".

      %(decorate[:<option>,...])

      імена посилань з оформленням користувача. За рядком decorate може йти двокрапка та нуль або більше параметрів, розділених комами. Значення параметрів можуть містити літеральні коди форматування. Їх необхідно використовувати для коми (%x2C) та закриваючої дужки (%x29) через їхню роль у синтаксисі параметрів.

      • prefix=<value>: Відображається перед списком імен посилань. Зазвичай " (".

      • suffix=<value>: Відображається після списку імен посилань. Зазвичай ")".

      • separator=<value>: Відображається між іменами посилань. Зазвичай ", ".

      • pointer=<value>: Відображається між HEAD та гілкою, на яку вона вказує, якщо така є. Зазвичай "  ".

      • tag=<value>: Відображається перед назвами тегів. Зазвичай "tag: ".

    Наприклад, для створення декорацій без обтікання чи анотацій тегів, з пробілами як роздільниками:

    %(decorate:prefix=,suffix=,tag=,separator= )

    %(describe[:<option>,...])

    зрозуміле для людини імʼя, як-от git-describe[1]; порожній рядок для комітів, які неможливо описати. За рядком describe може йти двокрапка та нуль або більше опцій, розділених комами. Описи можуть бути суперечливими, якщо теги додаються або видаляються одночасно.

    • tags[=<bool-value>]: Замість того, щоб розглядати лише анотовані теги, розгляньте також легкі теги.

    • abbrev=<number>: Замість використання стандартної кількості шістнадцяткових цифр (яка змінюватиметься залежно від кількості обʼєктів у репозиторії, зазвичай — 7) скороченої назви обʼєкта, використовуйте <number> цифр або стільки цифр, скільки потрібно для формування унікальної назви обʼєкта.

    • match=<шаблон>: Розглядати лише теги, що відповідають заданому шаблону glob(7) <шаблон>, виключаючи префікс refs/tags/.

    • exclude=<pattern>: Не враховувати теги, що відповідають заданому шаблону glob(7) <pattern>, за винятком префікса refs/tags/.

    %S

    імʼя посилання, вказане в командному рядку, за яким коміт було знайдено (наприклад, git log --source), працює лише з git log

    %e

    кодування

    %s

    тема

    %f

    очищений рядок теми, що підходить для імені файлу

    %b

    тіло

    %B

    необроблене тіло (тема без перенесення на новий рядок та тіло)

    %GG

    необроблене повідомлення перевірки від GPG для підписаного коміту

    %G?

    показувати «G» для правильного (дійсного) підпису, «B» для неправильного підпису, «U» для правильного підпису з невідомою дійсністю, «X» для правильного підпису, термін дії якого закінчився, «Y» — для дійсного підпису, створеного за допомогою ключа, термін дії якого закінчився, «R» — для дійсного підпису, створеного за допомогою скасованого ключа, «E» — якщо підпис не можна перевірити (наприклад, відсутній ключ) та «N» — для відсутності підпису

    %GS

    показати імʼя підписанта для підписаного коміту

    %GK

    показати ключ, який використовується для підписання підписаного коміту

    %GF

    показати відбиток ключа, який використовується для підписання підписаного коміту

    %GP

    показати відбиток первинного ключа, підрозділ якого було використано для підписання підписаного коміту

    %GT

    показати рівень довіри для ключа, який використовується для підписання підписаного коміту

    %gD

    селектор reflog, наприклад, refs/stash@{1} або refs/stash@{2 minutes ago}; формат відповідає правилам, описаним для опції -g. Частина перед @ — це імʼя посилання, як зазначено в командному рядку (тому git log -g refs/heads/master поверне refs/heads/master@{0}).

    %gd

    скорочений селектор reflog; те саме, що й %gD, але частина refname скорочена для зручності читання людиною (тому refs/heads/master стає просто master).

    %gn

    імʼя ідентифікатора reflog

    %gN

    імʼя ідентифікатора reflog (відповідно до .mailmap, див. git-shortlog[1] або git-blame[1])

    %ge

    електронна пошта ідентифікатора в reflog

    %gE

    електронна пошта ідентифікатора reflog (відповідно до .mailmap, див. git-shortlog[1] або git-blame[1])

    %gs

    тема reflog

    %(trailers[:<option>,...])

    показувати трейлери тіла повідомлення, як їх інтерпретує git-interpret-trailers[1]. За рядком trailers може йти двокрапка та нуль або більше опцій, розділених комами. Якщо якась опція вказана кілька разів, враховується останнє її вживання.

    • key=<ключ>: показувати лише трейлери з вказаним <ключ>. Зіставлення виконується без урахування регістру, а двокрапка в кінці є необовʼязковою. Якщо опція вказана кілька разів, відображаються рядки трейлера, що відповідають будь-якому з ключів. Ця опція автоматично вмикає опцію only, щоб приховувати рядки, що не є трейлерами, у блоці трейлера. Якщо це небажано, її можна вимкнути за допомогою only=false. Наприклад, %(trailers:key=Reviewed-by) показує рядки трейлера з ключем Reviewed-by.

    • only[=<bool>]: виберіть, чи слід включати не-трейлери рядків з трейлерного блоку.

    • separator=<sep>: вкажіть роздільник, що вставляється між рядками-трейлерами. Зазвичай використовується символ переведення рядка. Рядок <sep> може містити літеральні коди форматування, описані вище. Щоб використовувати кому як роздільник, необхідно використовувати %x2C, оскільки в іншому випадку він буде проаналізований як наступний параметр. Наприклад, %(trailers:key=Ticket,separator=%x2C) показує всі рядки-завершення, ключем яких є "Ticket", розділені комою та пробілом.

    • unfold[=<bool>]: змусити поводитися так, ніби для interpret-trailer було задано опцію --unfold. Наприклад, %(trailers:only,unfold=true) розгортає та показує всі рядки трейлера.

    • keyonly[=<bool>]: показувати тільки частину ключ трейлера.

    • valueonly[=<bool>]: показувати тільки частину значення трейлера.

    • key_value_separator=<sep>: визначає роздільник, що вставляється між ключем і значенням кожного трейлера. Зазвичай використовується значення ": ". В іншому випадку він має ту саму семантику, що й separator=<sep> вище.

Note
Деякі заповнювачі можуть залежати від інших параметрів, переданих механізму послідовного перегляду версій. Наприклад, параметри %g* reflog вставлятимуть порожній рядок, якщо ми не переглядаємо записи журналу змін (наприклад, за допомогою команди git log -g). Заповнювачі %d та %D використовуватимуть «короткий» формат оформлення, якщо параметр --decorate не було вказано в командному рядку.

Булеві параметри приймають необов’язкове значення [=<булеве-значення>]. Приймаються всі значення, які використовуються в параметрі --type=bool git-config[1], наприклад yes та off. Вказання булевого параметра без =<значення> еквівалентно вказанню його з =true.

Якщо додати знак «» (плюс) після +% заповнювача, переведення рядка вставляється безпосередньо перед розгортанням тоді і тільки тоді, коли заповнювач розгортається до непорожнього рядка.

Якщо додати знак "-" (мінус) після % заповнювача, усі послідовні переведення рядка безпосередньо перед розгортанням видаляються тоді і тільки тоді, коли заповнювач розгортається до порожнього рядка.

Якщо додати (пробіл) після % заповнювача, пробіл вставляється безпосередньо перед розкриттям тоді і тільки тоді, коли заповнювач розкривається до непорожнього рядка.

  • tformat:

    Формат tformat: працює точно так само, як format:, за винятком того, що він надає семантику "terminator" замість семантики "separator". Іншими словами, до кожного коміту додається символ завершення повідомлення (зазвичай це новий рядок), а не роздільник, розміщений між записами. Це означає, що останній запис однорядкового формату буде належним чином завершуватися новим рядком, як і у форматі "oneline". Наприклад:

    $ git log -2 --pretty=format:%h 4da45bef \
      | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
    4da45be
    7134973 -- NO NEWLINE
    
    $ git log -2 --pretty=tformat:%h 4da45bef \
      | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/'
    4da45be
    7134973

    Крім того, будь-який нерозпізнаний рядок, що містить символ %, інтерпретується так, ніби перед ним стоїть tformat:. Наприклад, ці дві команди є еквівалентними:

    $ git log -2 --pretty=tformat:%h 4da45bef
    $ git log -2 --pretty=%h 4da45bef

ПРИКЛАДИ

  • Вивести список комітів, доступних з поточної гілки.

    git rev-list HEAD
  • Вивести список комітів у цій гілці, але тих, що відсутні у гілці upstream.

    git rev-list @{upstream}..HEAD
  • Форматуйте коміти з їхнім автором та повідомленням коміта (див. також посилання на git-log[1]).

    git rev-list --format=medium HEAD
  • Форматувати коміти разом з їхніми різницями (див. також porcelain git-log[1], який може зробити це за один процес).

    git rev-list HEAD |
    git diff-tree --stdin --format=medium -p
  • Вивести список комітів у поточній гілці, які торкнулися будь-якого файлу в каталозі Documentation.

    git rev-list HEAD -- Документація/
  • Виведіть список комітів, створених вами за минулий рік, на будь-якій гілці, тегу чи іншому посиланні.

    git rev-list --author=you@example.com --since=1.year.ago --all
  • Вивести список об’єктів, досяжних з поточної гілки (тобто всі коміти та блоби й дерева, які вони містять).

    git rev-list --objects HEAD
  • Порівняйте розмір диска всіх доступних об’єктів з тими, що доступні з reflogs, та загальний розмір упакованого файлу. Це може показати вам, чи може виконання команди git repack -ad зменшити розмір репозиторію (шляхом видалення недоступних об’єктів), і чи можуть допомогти reflogs, термін дії яких закінчується.

    # reachable objects
    git rev-list --disk-usage --objects --all
    # plus reflogs
    git rev-list --disk-usage --objects --all --reflog
    # total disk size used
    du -c .git/objects/pack/*.pack .git/objects/??/*
    # alternative to du: add up "size" and "size-pack" fields
    git count-objects -v
  • Повідомляти про розмір диска кожної гілки, не враховуючи об’єкти, що використовуються поточною гілкою. Це може виявити викиди, які сприяють роздуттю розміру репозиторію (наприклад, через те, що хтось випадково закомітив великі артефакти збірки).

    git for-each-ref --format='%(refname)' |
    while read branch
    do
    	size=$(git rev-list --disk-usage --objects HEAD..$branch)
    	echo "$size $branch"
    done |
    sort -n
  • Порівняйте розмір гілок на диску в одній групі посилань, виключаючи іншу. Якщо ви змішуєте об’єкти з кількох віддалених серверів в одному репозиторії, це може показати, які віддалені сервери сприяють розміру репозиторію (беручи розмір origin за базовий).

    git rev-list --disk-usage --objects --remotes=$suspect --not --remotes=origin

GIT

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