Git

git-log last updated in 2.53.0

НАЗВА

git-log — Перегляд журналів комітів

СИНОПСИС

git log [<options>] [<revision-range>] [[--] <path>…]

ОПИС

Показує журнали комітів.

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

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

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

$ git log foo bar ^baz

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

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

$ git log origin..HEAD
$ git log HEAD ^origin

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

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

Команда використовує опції, що застосовуються до команди git-rev-list[1], для керування тим, що і як відображається, а також опції, що застосовуються до команди git-diff[1], для керування тим, як відображаються зміни, внесені кожним комітом.

ОПЦІЇ

--follow

Продовжити перегляд історії файлу, незважаючи на зміни імені (працює лише для одного файлу).

--no-decorate

--decorate[=(short|full|auto|no)]

Виводити назви посилань усіх показаних комітів. Можливі значення:

`short`;; префікси імен посилань `refs/heads/`, `refs/tags/` та
	`refs/remotes/` не відображаються.
`full`;; повне імʼя посилання (включаючи префікс) відображається.
`auto`:: якщо вивід йде в термінал, імена посилань
	відображаються так, ніби вказано `short`, інакше імена посилань
	не відображаються.

Опція --decorate є скороченим варіантом для --decorate=short. Типово використовується значення параметра log.decorate, якщо налаштовано, інакше auto.

--decorate-refs=<pattern>

--decorate-refs-exclude=<pattern>

Не використовуйте для оформлення кожного потенційного посилання, якщо воно відповідає будь-якому з параметрів <pattern>, вказаних для --decorate-refs-exclude, або якщо воно не відповідає жодному з параметрів <pattern>, вказаних для --decorate-refs. Параметр конфігурації log.excludeDecoration дозволяє виключити посилання з оформлення, але явно вказаний шаблон --decorate-refs матиме пріоритет над збігом у log.excludeDecoration.

Якщо жоден із цих параметрів або налаштувань конфігурації не вказано, то посилання використовуються як декоративні елементи, якщо вони відповідають HEAD, refs/heads/, refs/remotes/, refs/stash/ або refs/tags/.

--clear-decorations

Якщо вказано, ця опція скасовує всі попередні налаштування --decorate-refs або --decorate-refs-exclude та розширює стандартний фільтр декорування, щоб включити всі посилання. Ця опція вважається встановленою, якщо значення конфігурації log.initialDecorationSet встановлено на all.

--source

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

--mailmap

--no-mailmap

--use-mailmap

--no-use-mailmap

За допомогою файлу mailmap виконувати зіставлення імен авторів та авторів комітів, а також їхніх електронних адрес із канонічними справжніми іменами та електронними адресами. Див. git-shortlog[1].

--full-diff

Без цього прапорця команда git log -p <шлях>... показує коміти, які зачіпають вказані шляхи, та відмінності щодо тих самих вказаних шляхів. З цим прапорцем для комітів, які зачіпають вказані шляхи, показується повний список відмінностей; це означає, що "<шлях>..." обмежує лише коміти, але не обмежує список відмінностей для цих комітів.

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

--log-size

Включити рядок log size <число> у вивід для кожного коміту, де <число> — це довжина повідомлення цього коміту в байтах. Призначено для пришвидшення роботи інструментів, які зчитують повідомлення журналу з виводу git log, надаючи їм можливість заздалегідь виділити необхідний простір.

-L<start>,<end>:<file>

-L:<funcname>:<file>

Простежте зміну діапазону рядків, заданого параметрами <start>,<end> або регулярним виразом імені функції <funcname>, у файлі <file>. Ви не можете вказувати жодних обмежувачів шляху. Наразі це обмежено проходженням, що починається з однієї ревізії, тобто ви можете вказати лише нуль або один додатний аргумент ревізії, а <start> та <end> (або <funcname>) повинні існувати у початковій ревізії. Ви можете вказати цю опцію більше ніж один раз. Мається на увазі --patch. Вивід латок можна придушити за допомогою --no-patch, але інші формати порівняння (а саме --raw, --numstat, --shortstat, --dirstat, --summary, --name-only, --name-status, --check) наразі не реалізовані.

<start> і <end> може мати одну з цих форм:

<number>

Якщо <start> або <end> є числом, воно визначає абсолютний номер рядка (рядки рахуються від 1).
/<regex>/

Ця форма використовуватиме перший рядок, що відповідає заданому POSIX-виразу <regex>. Якщо <start> є регулярним виразом, пошук розпочнеться з кінця попереднього діапазону -L, якщо такий є, інакше — з початку файлу. Якщо <start> є ^/<regex>/, пошук розпочнеться з початку файлу. Якщо <end> є регулярним виразом, пошук розпочнеться з рядка, вказаного в <start>.
+<offset> або -<offset>

Є дійсним лише для <end> та визначатиме кількість рядків до або після рядка, заданого <start>.

Якщо :<funcname> вказано замість <start> та <end>, це регулярний вираз, який позначає діапазон від першого рядка funcname, що відповідає <funcname>, до наступного рядка funcname. :<funcname> шукає з кінця попереднього діапазону -L, якщо такий є, інакше з початку файлу. ^:<funcname> шукає з початку файлу. Назви функцій визначаються так само як git diff обчислює заголовки латок (див. «Визначення власного заголовка фрагмента» у gitattributes[5]).

<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

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

Ця опція також змінює стандартний формат diff для комітів злиття на first-parent, див. --diff-merges=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> для цього запису), залежно від кількох правил:

Якщо початкова точка вказана як ref@{<Nth>}, показати формат індексу.
Якщо початкова точка була вказана як ref@{now}, показати формат позначки часу.
Якщо жоден з них не був використаний, але в командному рядку було вказано --date, показати позначку часу у форматі, що запитується --date.
В іншому випадку, показати формат індексу.

У розділі --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 (підлягають видаленню за допомогою спрощення).

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

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

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

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

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

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

--notes[=<ref>]

Показувати нотатки (див. git-notes[1]), що анотують коміт, під час показу повідомлення журналу комітів. Це стандартне значення для команд git log, git show та git whatchanged, якщо в командному рядку не вказано параметри --pretty, --format або --oneline.

Стандартно показуються нотатки з посилань, зазначених у змінних core.notesRef та notes.displayRef (або у відповідних налаштуваннях середовища). Докладнішу інформацію див. у git-config[1].

Якщо вказано додатковий аргумент <ref>, використовувати посилання для пошуку приміток, які потрібно вивести. Посилання може містити повне імʼя, якщо воно починається з refs/notes/; якщо воно починається з notes/, до нього додається префікс refs/, а в інших випадках — refs/notes/, щоб утворити повне імʼя посилання.

Можна комбінувати кілька опцій --notes, щоб керувати тим, які нотатки відображатимуться. Приклади: «--notes=foo» покаже лише нотатки з refs/notes/foo; «--notes=foo --notes» покаже як нотатки з «refs/notes/foo», так і нотатки зі стандартних посилань.

--no-notes

Не показувати нотатки. Ця опція скасовує дію вищезазначеної опції --notes, скидаючи список посилань на нотатки, з яких вони виводяться. Опції обробляються у тому порядку, в якому вони вказані в командному рядку, тому, наприклад, команда «--notes --notes=foo --no-notes --notes=bar» покаже лише нотатки з refs/notes/bar.

--show-notes-by-default

Показувати стандартні нотатки, якщо не задано опції показу конкретних нотаток.

--show-notes[=<ref>]

--standard-notes

--no-standard-notes

Ці опції застарілі. Натомість використовуйте наведені вище опції --notes/--no-notes.

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

--parents

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

--children

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

--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>, буде показано саме цей рядок, а не стандартний рядок.

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

Якщо коміт є злиттям, і якщо 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

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

%N

нотатки коміту

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

ФОРМАТУВАННЯ DIFF

Зазвичай, git log не генерує жодного виводу diff. Наведені нижче опції можна використовувати для відображення змін, внесених кожним комітом.

Зверніть увагу, що якщо явно не вказано один із варіантів --diff-merges (включаючи короткі опції -m, -c, --cc та --dd), коміти злиття не відображатимуть diff, навіть якщо вибрано формат різниці, такий як --patch, а також не відповідатимуть опціям пошуку, таким як -S. Винятком є випадок, коли використовується --first-parent, і в цьому випадку first-parent є стандартним форматом для комітів злиття.

-p

-u

--patch

Створення латки (див. Генерація тексту латки за допомогою -p).

-s

--no-patch

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

-m

Показує відмінності для комітів злиття у стандартному форматі. Це схоже на --diff-merges=on, за винятком того, що -m не видаватиме жодних даних, якщо не вказано також -p.

-c

Створює вивід обʼєднаних відмінностей для комітів злиття. Скорочення для --diff-merges=combined -p.

--cc

Створює щільний вивід обʼєднаних відмінностей для комітів злиття. Скорочення для --diff-merges=dense-combined -p.

--dd

Створює diff відносно першого предка як для злиття, так і для звичайних комітів. Скорочений варіант для --diff-merges=first-parent -p.

--remerge-diff

Створює вивід remerge-diff для комітів злиття. Скорочений варіант для --diff-merges=remerge -p.

--no-diff-merges

Синонім до --diff-merges=off.

--diff-merges=<формат>

Вказує формат diff, який буде використовуватися для злиття комітів. Стандартним є `off`, якщо не використовується опція --first-parent; у цьому випадку стандартним є first-parent.

Підтримуються такі формати:

off
none: Вмикає виведення diff для комітів злиття. Корисно для заміни неявного значення.
on
m: Зробити так, щоб результати порівняння для злиття комітів відображалися у стандартному форматі. Стандартний формат можна змінити за допомогою параметра конфігурації log.diffMerges, стандартне значення якого — separate.
first-parent
1: Показати весь diff відносно першого батьківського елемента. Це той самий формат, який створює --patch для комітів без злиття.
separate: Показати весь diff стосовно кожного з батьків. Окремий запис журналу та diff створюється для кожного з батьків.
combined
c: Одночасно показувати відмінності від кожного з предків до результату злиття, замість того, щоб по черзі показувати парні відмінності між предком і результатом. Крім того, у списку відображаються лише ті файли, які були змінені порівняно з усіма предками.
dense-combined
cc: Подальше стиснення виводу, отриманого за допомогою --diff-merges=combined, шляхом пропускання нецікавих фрагментів, вміст яких у батьківських обʼєктах має лише два варіанти, і результат злиття вибирає один з них без змін.
remerge
r: Повторне обʼєднання двох батьківських комітів злиття для створення тимчасового обʼєкта дерева — який може містити файли з позначками конфліктів тощо. Після цього відображається порівняння між цим тимчасовим деревом і фактичним комітом злиття.

Вивід, що видається під час використання цієї опції, може змінюватися, як і її взаємодія з іншими опціями (якщо це явно не задокументовано).

--combined-all-paths

Змушує обʼєднані відмінності (які використовуються для комітів злиття) відображати імена файлів усіх батьківських комітів. Отже, ця опція діє лише за умови використання параметра --diff-merges=[dense-]combined і, ймовірно, буде корисною лише в разі виявлення змін у назвах файлів (тобто коли було задано виявлення перейменування або копіювання).

-U<n>

--unified=<n>

Генерувати diff з <n> рядками контексту замість звичайних трьох. Мається на увазі --patch.

--output=<файл>

Вивід у вказаний файл замість stdout.

--output-indicator-new=<char>

--output-indicator-old=<char>

--output-indicator-context=<char>

Визначає символ, який використовуватиметься для позначення нових, старих або контекстних рядків у згенерованій латці. Зазвичай це відповідно +, - та “ ”.

--raw

Для кожного коміту показати підсумок змін за допомогою raw diff формат. Див. розділ «ВИХІДНИЙ ФОРМАТ RAW» git-diff[1]. Це відрізняється від відображення журналу в необробленому форматі, чого можна досягти за допомогою --format=raw.

--patch-with-raw

Синонім до -p --raw.

-t

Показати обʼєкти дерева у виводі diff.

--indent-heuristic

Увімкнути евристику, яка зсуває межі фрагментів diff, щоб зробити латки легшими для читання. Це стандартне значення.

--no-indent-heuristic

Вимкнути евристику відступів.

--minimal

Витрачає додатковий час, щоб переконатися, що отримано найменший можливий diff.

--patience

Створювати diff використовуючи алгоритм "patience diff".

--histogram

Створювати diff використовуючи алгоритм "histogram diff".

--anchored=<text>

Створювати diff використовуючи алгоритм "anchored diff".

Цей параметр можна вказати більше одного разу.

Якщо рядок існує як у вихідному, так і в цільовому тексті, зустрічається лише один раз і починається з <текст>, цей алгоритм намагається запобігти його появі у вигляді видалення або додавання у результаті. Внутрішньо він використовує алгоритм «patience diff».

--diff-algorithm=(patience|minimal|histogram|myers)

Вибір алгоритму порівняння. Є наступні варіанти:

default
myers: Базовий алгоритм «жадібного» порівняння. Наразі це типове значення.
minimal: Витрачає додатковий час, щоб переконатися, що отримано найменший можливий diff.
patience: При створенні латок використовується алгоритм «patience diff».
histogram: Цей алгоритм розширює алгоритм «patience» для «підтримки рідкісних загальних елементів».

Наприклад, якщо ви налаштували змінну diff.algorithm на значення, відмінне від стандартного, і хочете скористатись стандартним значенням, тоді вам потрібно використовувати опцію --diff-algorithm=default.

--stat[=<width>[,<name-width>[,<count>]]]

Генерує diffstat. Як правило, для частини з іменами файлів використовується стільки місця, скільки потрібно, а решта — для частини з таблицями. Стандартна максимальна ширина дорівнює ширині терміналу або 80 стовпців, якщо підключення до терміналу відсутнє; це значення можна змінити за допомогою параметра <width>. Ширину частини імені файлу можна обмежити, вказавши іншу ширину <name-width> після коми або встановивши diff.statNameWidth=<name-width>. Ширину частини таблиці можна обмежити, використовуючи --stat-graph-width=<graph-width> або встановивши diff.statGraphWidth=<graph-width>. Використання --stat або --stat-graph-width впливає на всі команди, що генерують граф статистики, тоді як встановлення diff.statNameWidth або diff.statGraphWidth не впливає на git format-patch. Вказавши третій параметр <count>, ви можете обмежити вивід першими <count> рядками, за якими слідує ..., якщо їх більше.

Ці параметри також можна встановити окремо за допомогою --stat-width=<ширина>, --stat-name-width=<ширина-назви> та --stat-count=<кількість>.

--compact-summary

Виводити у diffstat стислий звіт про інформацію розширеного заголовка, таку як створення або видалення файлів («new» або «gone», за бажанням із позначкою +l, якщо це символічне посилання), а також зміни прав доступу (+x або -x для додавання чи видалення біта виконуваності відповідно). Ця інформація розміщується між частиною з іменем файлу та частиною з графом. Передбачає використання опції --stat.

--numstat

Подібно до --stat, але показує кількість доданих та видалених рядків у десятковому форматі та шлях без скорочень, що робить його зручнішим для машинної обробки. Для бінарних файлів виводить два - замість 0 0.

--shortstat

Виводіть лише останній рядок формату --stat, що містить загальну кількість змінених файлів, а також кількість доданих та видалених рядків.

-X [<param>,...]

--dirstat[=<param>,...]

Виводіть розподіл відносної кількості змін для кожної субтеки. Поведінку --dirstat можна налаштувати, передавши список параметрів, розділених комами. Стандартне значення контролюються змінною конфігурації diff.dirstat (див. git-config[1]). Доступні такі параметри:

changes: Обчислює показники dirstat шляхом підрахунку рядків, які були видалені з вихідного файлу або додані до файлу призначення. При цьому не враховується кількість переміщень коду всередині самого файлу. Іншими словами, перегрупування рядків у файлі не враховується так само, як інші зміни. Це стандартна поведінка, якщо параметр не вказано.
lines: Обчислює показники dirstat, виконуючи звичайний аналіз відмінностей на основі рядків та підсумовуючи кількість видалених/доданих рядків. (Для бінарних файлів рахує 64-байтові блоки, оскільки бінарні файли не мають природного поняття рядків). Такий підхід --dirstat є більш ресурсоємним, ніж підхід changes, але він враховує перегруповані рядки у файлі нарівні з іншими змінами. Отриманий результат відповідає тому, що ви отримуєте від інших опцій --*stat.
files: Обчислює показники dirstat, рахуючи кількість змінених файлів. Кожен змінений файл має однакову вагу в аналізі dirstat. Це найменш ресурсомісткий варіант роботи опції --dirstat, оскільки він взагалі не вимагає аналізу вмісту файлів.
cumulative: Також підраховуються зміни у дочірній теці батьківської теки. Зверніть увагу, що при використанні параметра cumulative сума вказаних відсотків може перевищувати 100%. Стандартну поведінку (без накопичення) можна вказати за допомогою параметра noncumulative.
<limit>: Цілочисельний параметр визначає граничний відсоток (стандартно — 3%). Теки, що вносять менше змін, ніж цей відсоток, не відображаються у виводі.

Приклад: Наступна команда підрахує змінені файли, ігноруючи при цьому теки, в яких міститься менше ніж 10 % від загальної кількості змінених файлів, та підсумовуючи кількість файлів у дочірніх теках в батьківських теках: --dirstat=files,10,cumulative.

--cumulative

Синонім до --dirstat=cumulative.

--dirstat-by-file[=<param>,...]

Синонім до --dirstat=files,<param>,....

--summary

Виводить стислий підсумок інформації розширеного заголовка, такої як створення, перейменування та зміни режиму.

--patch-with-stat

Синонім до -p --stat.

-z

Розділяйте коміти символами NUL замість символів нового рядка.

Також, коли вказано --raw або --numstat, не змінювати шляхи та використовуйте NUL як символи завершення полів виводу.

Без цієї опції шляхи з «незвичайними» символами беруться в лапки, як це пояснено для змінної конфігурації core.quotePath (див. git-config[1]).

--name-only

Показувати лише назву кожного зміненого файлу в дереві пост-образів. Назви файлів часто кодуються в UTF-8. Для отримання додаткової інформації див. обговорення кодування на сторінці довідки git-log[1].

--name-status

Показувати лише імʼя(імена) та стан кожного зміненого файлу. Дивіться опис опції --diff-filter щодо значення літер стану. Так само як і --name-only, імена файлів часто кодуються в UTF-8.

--submodule[=<формат>]

Визначає, як відображатимуться відмінності в субмодулях. Для --submodule=short використовується формат short. Цей формат показує лише імена комітів на початку та в кінці діапазону. Якщо вказано --submodule або --submodule=log, використовується формат log. Цей формат перелічує коміти в діапазоні, як це робить git-submodule[1] summary. При вказанні --submodule=diff використовується формат diff. Цей формат показує порівняння змін у вмісті субмодуля між діапазоном комітів. Стандартним є diff.submodule або формат short, якщо опція конфігурації не встановлена.

--color[=<when>]

Показує відмінності з кольоровою підсвіткою. --color (тобто без =<when>) те саме, що й --color=always. <when> може бути одним із always, never або auto.

--no-color

Вимикає кольорову підсвітку відмінностей. Це те саме, що --color=never.

--color-moved[=<режим>]

Переміщені рядки коду забарвлюються по-різному. Якщо параметр не вказано, типовим значенням для <режим> є no, а якщо вказано параметр без режиму — zebra. Режим повинен бути одним із таких:

no: Переміщені рядки не підсвічуються.
default: Є синонімом zebra. У майбутньому це може змінитися на раціональніший режим.
plain: Будь-який рядок, який було додано в одному місці та видалено в іншому, буде виділено кольором color.diff.newMoved. Аналогічно, колір color.diff.oldMoved застосовуватиметься до видалених рядків, які було додано в іншому місці в відмінностях. Цей режим виявляє будь-які переміщені рядки, але під час рецензування він не дуже корисний для визначення того, чи було переміщено блок коду без зміни порядку.
blocks: Блоки переміщеного тексту, що містять щонайменше 20 літерно-цифрових символів, виявляються за алгоритмом «greedy». Виявлені блоки зафарбовуються кольором color.diff.(old|new)Moved. Суміжні блоки неможливо розрізнити.
zebra: Блоки переміщеного тексту виявляються як у режимі blocks. Блоки зафарбовуються кольором color.diff.(old|new)Moved або color.diff.(old|new)MovedAlternative. Зміна між двома кольорами вказує на виявлення нового блоку.
dimmed-zebra: Подібно до zebra, але виконується додаткове затемнення нецікавих частин переміщеного коду. Лінії, що межують з двома суміжними блоками, вважаються цікавими, решта — нецікавими. dimmed_zebra — застарілий синонім.

--no-color-moved

Вимикає виявлення переміщення. Цю опцію можна використовувати для заміни параметрів конфігурації. Вона відповідає параметру --color-moved=no.

--color-moved-ws=<режим>,...

Налаштовує, як ігноруються пробіли під час виконання виявлення переміщення для --color-moved. Ці режими можна вказати у вигляді списку, розділеного комами:

no: Не ігнорувати пробіли під час виявлення переміщення.
ignore-space-at-eol: Ігнорувати зміни пробілів в кінці рядків.
ignore-space-change: Ігнорувати зміни кількості пробілів. Ігнорує пробіли в кінці рядка та вважає всі інші послідовності з одного або кількох пробільних символів еквівалентними.
ignore-all-space: Ігнорувати пробіли під час порівняння рядків. Ігнорує відмінності, навіть якщо один рядок має пробіли, а інший їх не має.
allow-indentation-change: Спочатку ігнорувати будь-які пробіли у виявленні переміщення, а потім групувати переміщені блоки коду в блок, лише якщо зміна пробілів однакова для кожного рядка. Це несумісно з іншими режимами.

--no-color-moved-ws

Не ігнорувати пробіли під час виявлення переміщення. Можна використовувати для перевизначення налаштувань конфігурації. Це те саме, що --color-moved-ws=no.

--word-diff[=<mode>]

Зазвичай слова розділяються пробілами; див. --word-diff-regex нижче. <mode> стандартно має значення plain і має бути одним з:

color: Виділяє змінені слова, використовуючи лише кольори. Мається на увазі --color.
plain: Показує слова як [-removed-] та {added}. Не намагається екранувати роздільники, якщо вони зʼявляються у вхідних даних, тому вивід може бути неоднозначним.
porcelain: Використовує спеціальний рядковий формат, призначений для використання скриптами. Додані/видалені/незмінені прогони виводяться у звичайному уніфікованому форматі відмінностей, починаючи з символу +/-/` ` на початку рядка та продовжуючи до кінця рядка. Перехід на новий рядок у вхідних даних позначається тильдою ~ на окремому рядку.
none: Знову вимкнути порівняння слів.

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

--word-diff-regex=<regex>

Використовуйте <regex> для визначення того, що є словом, замість того, щоб вважати послідовності символів, що не є пробілами, словами. Також передбачає використання параметра --word-diff, якщо він ще не був увімкнений.

Всі збіги виразу <regex>, що не перекриваються, вважаються словами. Все, що знаходиться між цими збігами, вважається пробілами та ігнорується(!) під час пошуку відмінностей. Можливо, вам варто додати |[^[:space:]] до вашого регулярного виразу, щоб переконатися, що він відповідає всім символам, які не є пробілами. Збіг, що містить символ нового рядка, без попередження обрізається(!) на цьому символі.

Наприклад, --word-diff-regex=. трактуватиме кожен символ як слово та, відповідно, показуватиме відмінності посимвольно.

Регулярний вираз також можна задати за допомогою драйвера порівняння або параметра конфігурації; див. gitattributes[5] або git-config[1]. Явне вказання цього параметра має пріоритет над будь-якими налаштуваннями драйвера порівняння або конфігурації. Драйвери порівняння мають пріоритет над налаштуваннями конфігурації.

--color-words[=<regex>]

Еквівалентно --word-diff=color плюс (якщо було вказано регулярний вираз) --word-diff-regex=<regex>.

--no-renames

Вимикає виявлення перейменування, навіть якщо у файлі конфігурації це є стандартним.

--rename-empty

--no-rename-empty

Чи використовувати порожні блоби як джерело перейменування.

--check

Попереджає, якщо зміни призводять до появи маркерів конфлікту або помилок пробілів. Те, що вважається помилками пробілів, визначається параметром конфігурації core.whitespace. У стандартному режимі помилками пробілів вважаються пробіли в кінці рядка (включно з рядками, що складаються виключно з пробілів), а також пробіл, за яким одразу йде символ табуляції в межах початкового відступу рядка. У разі виявлення проблем закінчує роботу з ненульовим кодом стану. Несумісно з параметром --exit-code.

--ws-error-highlight=<kind>

Виділяє помилки пробілів у рядках context, old або new різниці. Кілька значень розділяються комами, none скидає попередні значення, default скидає список до new, а all — це скорочення від old,new,context. Якщо цей параметр не вказано, а змінна конфігурації diff.wsErrorHighlight не встановлена, виділяються лише помилки пробілів у рядках new. Помилки пробілів підсвічуються за допомогою color.diff.whitespace.

--full-index

Замість перших кількох символів, відображати повні назви обʼєктів blob для пре- та пост-образів в рядку "index" під час створення виводу у форматі латки.

--binary

Окрім --full-index, виводити бінарний diff, який можна застосувати за допомогою git-apply. Мається на увазі --patch.

--abbrev[=<n>]

Замість повного 40-байтового шістнадцяткового імені об’єкта у вихідних даних формату diff-raw та у заголовках рядків diff-tree показувати найкоротший префікс довжиною не менше <n> шістнадцяткових цифр, який однозначно ідентифікує об’єкт. У форматі виводу diff-patch опція --full-index має вищий пріоритет, тобто якщо вказано --full-index, повні імена блобів будуть показані незалежно від --abbrev. Нестандартну кількість цифр можна вказати за допомогою --abbrev=<n>.

-B[<n>][/<m>]

--break-rewrites[=[<n>][/<m>]]

Розбивати повні зміни перезапису на пари видалення та створення. Це служить двом цілям:

Це впливає на те, як зміна, яка зводиться до повного перезапису файлу, представляється не як серія видалення та вставки, змішаних разом з дуже невеликою кількістю рядків, які випадково відповідають контексту, а як одне видалення всього старого, за яким слідує одна вставка всього нового, і число <m> контролює цей аспект опції -B (типово — 60%). -B/70% вказує, що менше 30% оригіналу має залишитися в результаті, щоб Git вважав це повним перезаписом (тобто інакше отримана латка буде серією видалення та вставки, змішаних разом з рядками контексту).

При використанні з -M, повністю перезаписаний файл також вважається джерелом перейменування (зазвичай -M розглядає лише файл, який зник, як джерело перейменування), а число <n> контролює цей аспект опції -B (стандартно — 50%). -B20% вказує на те, що зміна з додаванням та видаленням порівняно з 20% або більше від розміру файлу може бути розглянута як можливе джерело перейменування на інший файл.

-M[<n>]

--find-renames[=<n>]

Під час формування списку змін слід виявляти та повідомляти про перейменування для кожного коміту. Щоб відстежувати файли після їх перейменування під час перегляду історії, див. опцію --follow. Якщо вказано <n>, це означає поріг для індексу схожості (тобто частка доданих/видалених даних порівняно з розміром файлу). Наприклад, -M90% означає, що Git повинен розглядати пару «видалення/додавання» як перейменування, якщо більше ніж 90% файлу не змінилося. Без знака % число слід читати як дріб, з десятковою крапкою перед ним. Тобто -M5 стає 0,5, і, отже, дорівнює -M50%. Аналогічно, -M05 дорівнює -M5%. Щоб обмежити виявлення лише точними перейменуваннями, використовуйте -M100%. Стандартно індекс схожості становить 50%.

-C[<n>]

--find-copies[=<n>]

Виявляти копії, а також перейменування. Див. також --find-copies-harder. Якщо вказано <n>, це має те саме значення, що й -M<n>.

--find-copies-harder

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

-D

--irreversible-delete

Не відображати вихідний текст для видалень, тобто виводити лише заголовок, але не різницю між вихідним текстом та /dev/null. Отримана латка не призначена для застосування за допомогою patch або git apply; вона призначена виключно для тих, хто хоче зосередитися лише на перегляді тексту після внесення змін. Крім того, у виведеній інформації явно бракує даних, щоб застосувати таку латку у зворотному напрямку, навіть вручну, звідси й назва цієї опції.

При використанні разом з -B, також пропускається вихідний текст у частині видалення пари видалення/створення.

-l<num>

Параметри -M та -C передбачають виконання деяких попередніх кроків, які дозволяють економічно виявити підмножини випадків перейменування/копіювання, після чого виконується вичерпна резервна перевірка, під час якої всі залишені неспарені місця призначення порівнюються з усіма відповідними джерелами. (Для перейменувань релевантними є лише залишені неспарені джерела; для копіювань — усі оригінальні джерела.) Для N джерел та цілей ця вичерпна перевірка має складність O(N^2). Ця опція запобігає виконанню вичерпної частини виявлення перейменувань/копіювань, якщо кількість залучених файлів-джерел/файлів-цілей перевищує вказану кількість. Стандартне значення — diff.renameLimit. Зверніть увагу, що значення 0 трактується як необмежене.

--diff-filter=[(A|C|D|M|R|T|U|X|B)...[*]]

Вибирати лише файли, які додані (A), скопійовані (C), видалені (D), змінені (M), перейменовані (R), мають змінений тип (наприклад, звичайний файл, символічне посилання, субмодуль тощо) (T), не обʼєднані (U), невідомі (X) або мають розірвану пару (B). Можна використовувати будь-яку комбінацію символів фільтра (навіть жодного). Коли до комбінації додається * (все-або-нічого), усі шляхи вибираються, якщо в порівнянні є файл, який відповідає іншим критеріям; якщо файлів, що відповідають іншим критеріям, немає, нічого не вибирається.

Також ці великі літери можна писати в нижньому регістрі, щоб вказати зворотну дію. Наприклад, --diff-filter=ad не включає додані та видалені шляхи.

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

-S<string>

Шукає відмінності, які змінюють кількість входжень зазначеного <рядка> (тобто додавання/видалення) у файлі. Призначено для використання скриптером.

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

Також виконується пошук у бінарних файлах.

-G<regex>

Шукає відмінності, текст виправлення яких містить додані/видалені рядки, що відповідають <regex>.

Щоб проілюструвати різницю між -S<regex> --pickaxe-regex та -G<regex>, розглянемо коміт з наступним diff у тому ж файлі:

+    return frotz(nitfol, two->ptr, 1, 0);
...
-    hit = frotz(nitfol, mf2.ptr, 1, 0);

Хоча git log -G"frotz\(nitfol" покаже цей коміт, git log -S"frotz\(nitfol" --pickaxe-regex ні (оскільки кількість входжень цього рядка не змінилася).

Якщо не вказано параметр --text, фрагменти бінарних файлів без фільтра textconv будуть ігноруватися.

Дивіться опис «pickaxe» у gitdiffcore[7] для отримання додаткової інформації.

--find-object=<object-id>

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

Об’єктом може бути блоб або коміт субмодуля. Це має на увазі опцію -t у команді git-log, яка дозволяє також знаходити дерева.

--pickaxe-all

Коли -S або -G знаходить зміну, показати всі зміни в цьому наборі змін, а не лише файли, що містять зміну в <рядку>.

--pickaxe-regex

Обробляти <рядок>, переданий -S, як розширений регулярний вираз POSIX для збігу.

-O<файл-порядку>

Керує порядком, у якому файли відображаються у вихідних даних. Замінює значення конфігураційної змінної diff.orderFile (див. git-config[1]). Щоб скасувати дію diff.orderFile, використовуйте -O/dev/null.

Порядок виведення визначається порядком шаблонів у <файлі-порядку>. Спочатку виводяться всі файли, імена яких відповідають першому шаблону, потім — всі файли, імена яких відповідають другому шаблону (але не першому), і так далі. Усі файли, імена яких не відповідають жодному шаблону, виводяться останніми, ніби в кінці файлу був неявний шаблон, що відповідає всім. Якщо кілька імен мають однаковий ранг (вони відповідають одному й тому ж шаблону, але не відповідають попереднім шаблонам), їхній порядок виведення відносно один одного є звичайним.

<файл-порядку> має наступний синтаксис:

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

Шаблони мають той самий синтаксис і семантику, що й шаблони, що використовуються для fnmatch(3) без прапорця FNM_PATHNAME, за винятком того, що імʼя шляху також відповідає шаблону, якщо видалення будь-якої кількості компонентів кінцевого імені шляху відповідає шаблону. Наприклад, шаблон "foo*bar" відповідає "fooasdfbar" та "foo/bar/baz/asdf", але не "foobarx".

--skip-to=<файл>

--rotate-to=<файл>

Вилучіть із виводу файли, що йдуть перед файлом із іменем <file> (тобто «пропустити до»), або перемістіть їх у кінець виводу (тобто «перемістити до»). Ці параметри були розроблені переважно для використання з командою git difftool і в інших випадках можуть виявитися не надто корисними.

-R

Поміняти місцями два потоки вхідних даних; тобто показати відмінності між індексом або файлом на диску та вмістом дерева.

--relative[=<шлях>]

--no-relative

Якщо запускати з субтеки проєкту, за допомогою цього параметра можна вказати, щоб виключити зміни поза межами цієї теки та показувати шляхи відносно неї. Якщо ви не перебуваєте в субтеці (наприклад, у «голому» репозиторії), ви можете вказати, щодо якої саме субтеки має бути відносний вивід, передавши <path> як аргумент. --no-relative можна використовувати для скасування як опції конфігурації diff.relative, так і попереднього --relative.

-a

--text

Обробляти всі файли як текст.

--ignore-cr-at-eol

Ігнорувати символ повернення каретки в кінці рядка під час порівняння.

--ignore-space-at-eol

Ігнорувати зміни пробілів в кінці рядків.

-b

--ignore-space-change

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

-w

--ignore-all-space

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

--ignore-blank-lines

Ігнорувати зміни, рядки яких порожні.

-I<регулярний вираз>

--ignore-matching-lines=<регулярний вираз>

Ігнорувати зміни, усі рядки яких відповідають <регулярному виразу>. Цей параметр можна вказувати більше одного разу.

--inter-hunk-context=<number>

Показує контекст між фрагментами відмінностей (diff hunks), до вказаної <кількості> рядків, таким чином обʼєднуючи фрагменти, що знаходяться близько один до одного. Стандартно використовується значення diff.interHunkContext або 0, якщо параметр конфігурації не встановлено.

-W

--function-context

Показувати повну функцію у вигляді контекстних рядків для кожної зміни. Імена функцій визначаються так само як git diff обчислює заголовки фрагментів латок (див. «Визначення власного заголовка фрагмента» у gitattributes[5]).

--ext-diff

Дозволити виконання зовнішнього помічника diff. Якщо ви налаштували зовнішній драйвер diff за допомогою gitattributes[5], вам потрібно використовувати цю опцію разом із git-log[1] та подібними командами.

--no-ext-diff

Заборонити сторонні драйвери diff.

--textconv

--no-textconv

Дозволити (або заборонити) використання зовнішніх фільтрів перетворення тексту під час порівняння бінарних файлів. Див. gitattributes[5] для отримання детальної інформації. Оскільки фільтри textconv зазвичай є одностороннім перетворенням, отриманий diff придатний для використання людиною, але не може бути застосований. З цієї причини фільтри textconv стандартно увімкнено лише для git-diff[1] та git-log[1], але не для git-format-patch[1] або команд diff plumbing.

--ignore-submodules[=(none|untracked|dirty|all)]

Ігнорувати зміни в субмодулях під час формування порівняння. Стандартним значенням є all. При використанні none субмодуль вважатиметься зміненим, якщо він містить не відстежувані або змінені файли, або якщо його HEAD відрізняється від коміту, записаного в суперпроєкті; це дозволяє замінити будь-які налаштування параметра ignore у файлах git-config[1] або gitmodules[5]. При використанні untracked субмодулі не вважаються зміненими, якщо вони містять лише не відстежуваний вміст (але вони все одно скануються на наявність зміненого вмісту). Використання dirty ігнорує всі зміни у робочому дереві субмодулів, показуються лише зміни у комітах, збережених у суперпроекті (така поведінка була до версії 1.7.0). Використання all приховує всі зміни у субмодулях.

--src-prefix=<prefix>

Показати вказаний <prefix> для джерела замість "a/".

--dst-prefix=<prefix>

Показувати вказаний <prefix> для призначення замість "b/".

--no-prefix

Не показувати жодного префікса для джерела чи призначення.

--default-prefix

Використовувати типові префікси джерела та призначення ("a/" та "b/"). Замінює змінні конфігурації, такі як diff.noprefix, diff.srcPrefix, diff.dstPrefix та diff.mnemonicPrefix (див. git-config[1]).

--line-prefix=<prefix>

Додавати додатковий <prefix> до кожного рядка виводу.

--ita-invisible-in-index

Стандартно записи, додані за допомогою команди git add -N, відображаються як наявні порожні файли в git diff і як нові файли в git diff --cached. Ця опція забезпечує відображення запису як нового файлу в git diff і як файлу, що не існує, в git diff --cached. Дія цієї опції можна скасувати за допомогою --ita-visible-in-index. Обидві опції є експериментальними і можуть бути вилучені в майбутньому.

--max-depth=<depth>

Для кожного специфікатора шляху, вказаного в командному рядку, слід просканувати не більше ніж <depth> рівнів тек. Значення -1 означає відсутність обмеження. Не можна поєднувати з символами-замінниками у специфікаторі шляху. Якщо дерево містить foo/bar/baz, у наведеному нижче списку показано результати, отримані для кожного набору опцій:

--max-depth=0 -- foo: foo
--max-depth=1 -- foo: foo/bar
--max-depth=1 -- foo/bar: foo/bar/baz
--max-depth=1 -- foo foo/bar: foo/bar/baz
--max-depth=2 -- foo: foo/bar/baz

Якщо специфікатор шляху не вказано, глибина вимірюється так, ніби вказано всі записи верхнього рівня. Зверніть увагу, що це відрізняється від вимірювання від кореня тим, що при --max-depth=0 все одно буде повернуто foo. Це дозволяє обмежувати глибину, запитуючи при цьому лише підмножину записів верхнього рівня.

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

Для більш детального пояснення цих поширених опцій див. також gitdiffcore[7].

Генерація тексту латки за допомогою -p

Виконання команд git-diff[1], git-log[1], git-show[1], git-diff-index[1], git-diff-tree[1] або git-diff-files[1] з опцією -p створює текст латки. Ви можете налаштувати створення тексту латки за допомогою змінних середовища GIT_EXTERNAL_DIFF та GIT_DIFF_OPTS (див. git[1]), а також атрибута diff (див. gitattributes[5]).

Текст, який ви отримаєте з використанням опції -p, дещо відрізняється від традиційного формату diff:

Йому передує заголовок "git diff", який виглядає так:
```
diff --git a/file1 b/file2
```
Імена файлів a/ та b/ однакові, якщо не йдеться про перейменування/копіювання. Зокрема, навіть для створення або видалення, /dev/null не використовується замість імен файлів a/ або b/.

Коли йдеться про перейменування/копіювання, file1 та file2 показують відповідно назву вихідного файлу перейменування/копіювання та назву файлу, який створюється в результаті перейменування/копіювання.
За ним йде один або декілька рядків розширеного заголовка:
```
старий режим <режим>
новий режим <режим>
видалений файл режим <режим>
новий файл режим <режим>
копіювати з <шлях>
копіювати до <шлях>
перейменувати з <шлях>
перейменувати в <шлях>
індекс подібності <номер>
індекс несхожості <номер>
індекс <хеш>..<хеш> <режим>
```
Режими файлів <режим> виводиться у вигляді 6-значні вісімкових чисел, включаючи тип файлу та біти прав доступу до файлу.

Імена шляхів у розширених заголовках не містять префіксів a/ та b/.

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

Рядок індексу містить імена блоб-обʼєктів до та після зміни. <Режим> додається, якщо режим файлу не змінюється; інакше окремі рядки вказують на старий та новий режими.
Шляхи з «незвичайними» символами беруться в лапки, як це пояснено для змінної конфігурації core.quotePath (див. git-config[1]).
Усі файли file1 у виводі посилаються на файли до коміту, а всі файли file2 посилаються на файли після коміту. Неправильно застосовувати кожну зміну до кожного файлу послідовно. Наприклад, ця латка поміняє місцями a та b:
```
diff --git a/a b/b
rename from a
rename to b
diff --git a/b b/a
rename from b
rename to a
```
У заголовках фрагмента згадується назва функції, до якої він застосовується. Див. "Визначення власного заголовка фрагмента" в gitattributes[5] для отримання детальної інформації про те, як налаштувати це для конкретних мов (програмування).

Формат обʼєднаних відмінностей (combined diff)

Будь-яка команда, що генерує відмінності, може використовувати опцію -c або --cc для створення «обʼєднаних відмінностей» під час показу злиття. Це стандартний формат під час показу злиття за допомогою git-diff[1] або git-show[1]. Також зауважте, що ви можете надати відповідну опцію --diff-merges будь-якій із цих команд, щоб примусово генерувати відмінності у певному форматі.

Формат «обʼєднаних відмінностей» виглядає так:

diff --combined describe.c
index fabadb8,cc95eb0..4866510
--- a/describe.c
+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@
	return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;
  }

- static void describe(char *arg)
 -static void describe(struct commit *cmit, int last_one)
++static void describe(char *arg, int last_one)
  {
 +	unsigned char sha1[20];
 +	struct commit *cmit;
	struct commit_list *list;
	static int initialized = 0;
	struct commit_name *n;

 +	if (get_sha1(arg, sha1) < 0)
 +		usage(describe_usage);
 +	cmit = lookup_commit_reference(sha1);
 +	if (!cmit)
 +		usage(describe_usage);
 +
	if (!initialized) {
		initialized = 1;
		for_each_ref(get_name);

Йому передує заголовок "git diff", який виглядає ось так (коли використовується опція -c):
```
diff --combined file
```
або ось так (коли використовується опція --cc):
```
diff --cc file
```
За ним йде один або декілька розширених рядків заголовка (у цьому прикладі показано злиття з двома батьківськими обʼєктами):
```
індекс <hash>,<hash>..<hash>
режим <mode>,<mode>..<mode>
новий файловий режим <mode>
режим видаленого файлу <mode>,<mode>
```
Рядок mode <mode>,<mode>..<mode> зʼявляється лише тоді, коли хоча б один з <mode> відрізняється від решти. Розширені заголовки з інформацією про виявлене переміщення контенту (перейменування та виявлення копіювання) спроєктовані для роботи з diff двох <деревоподібних> обʼєктів і не використовуються форматом combined diff.
Далі йде дворядковий заголовок from-file/to-file:
```
--- a/файл
+++ б/файл
```
Подібно до дворядкового заголовка для традиційного «уніфікованого» формату diff, /dev/null використовується для повідомлення про створені або видалені файли.

Однак, якщо вказано опцію --combined-all-paths, замість дворядкового заголовка from-file/to-file ви отримаєте N+1 рядковий заголовок from-file/to-file, де N — кількість батьківських обʼєктів у коміті злиття:
```
--- a/файл
--- a/файл
--- a/файл
+++ б/файл
```
Цей розширений формат може бути корисним, якщо активовано виявлення перейменування або копіювання, щоб дозволити вам бачити оригінальну назву файлу в різних батьківських обʼєктах.
Формат заголовка фрагмента змінено, щоб запобігти випадковому передаванню його до patch -p1. Формат обʼєднаних відмінностей був створений для перегляду змін у комітах злиття та не призначався для їх впровадження. Зміна подібна до зміни в розширеному заголовку index:
```
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
```
У заголовку фрагмента є (кількість батьківських обʼєктів + 1) символи @ для формату обʼєднаних відмінностей.

На відміну від традиційного «уніфікованого» формату відмінностей, який показує два файли A та B з одним стовпцем із префіксом - (мінус — зʼявляється в A, але видалений в B), + (плюс — відсутній в A, але доданий до B) або " " (пробіл — без змін), цей формат порівнює два або більше файлів file1, file2,… з одним файлом X та показує, чим X відрізняється від кожного з fileN. Один стовпець для кожного з fileN додається до рядка виводу, щоб відзначити, чим рядок X відрізняється від нього.

Символ - у стовпці N означає, що рядок зʼявляється у файлі N, але не зʼявляється в результаті. Символ + у стовпці N означає, що рядок зʼявляється в результаті, а файл N не містить цього рядка (іншими словами, рядок було додано з погляду батьківського обʼєкта).

У наведеному вище прикладі виводу сигнатуру функції було змінено в обох файлах (отже, два видалення - з файлу file1 та файлу file2, плюс ++, що означає, що один доданий рядок не відображається ні у файлі file1, ні у файлі file2). Також, вісім інших рядків є такими як у файлі file1, але не відображаються у файлі file2 (отже, з префіксом +).

Коли цей формат виводиться за допомогою команди git diff-tree -c, він порівнює батьківські обʼєкти коміту злиття з результатом злиття (тобто file1..fileN є батьками). У виводі за допомогою команди git diff-files -c, він порівнює два нерозвʼязані батьківські обʼєкти злиття з файлом робочого дерева (тобто file1 — це stage 2, також відомий як "наша версія", file2 — це stage 3, також відомий як "їхня версія").

ПРИКЛАДИ

git log --no-merges: Показати всю історію комітів, але пропустити будь-які злиття
git log v2.6.12.. include/scsi drivers/scsi: Показати всі коміти, починаючи з версії v2.6.12, які змінили будь-який файл у субтеках include/scsi або drivers/scsi
git log --since="2 weeks ago" -- gitk: Показати зміни за останні два тижні у файлі gitk. -- необхідний, щоб уникнути плутанини з гілкою з назвою gitk
git log --name-status release..test: Показати коміти, що знаходяться у гілці "test", але ще не у гілці "release", разом зі списком шляхів, які змінює кожен коміт.
git log --follow builtin/rev-list.c: Показує коміти, що змінили builtin/rev-list.c, включаючи ті коміти, які відбулися до того, як файлу було надано його поточну назву.
git log --branches --not --remotes=origin: Показує всі коміти, що знаходяться в будь-якій з локальних гілок, але не в жодній з гілок віддаленого відстеження для origin (те, що у вас є, цього origin не відображає).
git log master --not --remotes=*/master: Показує всі коміти, які є в локальній гілці master, але відсутні в гілках master будь-якого віддаленого репозиторію.
git log -p -m --first-parent: Показує історію, включаючи порівняння змін, але лише з позиції «основної гілки», пропускаючи коміти, що походять із злитих гілок, та показуючи повні diff у результаті злиття. Це доцільно лише в разі дотримання суворої політики злиття всіх тематичних гілок при роботі в рамках єдиної гілки інтеграції.
git log -L /int main/',/^}/:main.c: Показує, як функція main() у файлі main.c розвивалася з часом.
git log -3: Обмежує кількість комітів для відображення до 3.

ОБГОВОРЕННЯ

Git певною мірою не залежить від кодування символів.

Вміст блоб-обʼєктів — це неінтерпретовані послідовності байтів. На рівні ядра немає перетворення кодування.
Імена шляхів закодовано у формі нормалізації UTF-8 C. Це стосується обʼєктів дерева, індексного файлу, імен посилань, а також імен шляхів в аргументах командного рядка, змінних середовища та конфігураційних файлах (.git/config (див. git-config[1]), gitignore[5], gitattributes[5] та gitmodules[5]).

Зверніть увагу, що Git на рівні ядра трактує шляхи просто як послідовності байтів, відмінних від NUL, немає перетворень кодування шляхів (за винятком Mac та Windows). Тому використання шляхів, відмінних від ASCII, здебільшого працюватиме навіть на платформах та файлових системах, які використовують застарілі розширені кодування ASCII. Однак репозиторії, створені на таких системах, не працюватимуть належним чином на системах на основі UTF-8 (наприклад, Linux, Mac, Windows) і навпаки. Крім того, багато інструментів на основі Git просто вважають шляхи UTF-8 і не відображатимуть інші кодування належним чином.
Повідомлення журналу комітів зазвичай кодуються в UTF-8, але також підтримуються інші розширені кодування ASCII. Це включає ISO-8859-x, CP125x та багато інших, але не UTF-16/32, EBCDIC та багатобайтові кодування CJK (GBK, Shift-JIS, Big5, EUC-x, CP9xx тощо).

Хоча ми рекомендуємо використовувати кодування повідомлень журналу комітів в UTF-8, як ядро, так і Git Porcelain розроблені таким чином, щоб не навʼязувати UTF-8 проєктам. Якщо всі учасники певного проєкту вважають зручнішим використовувати застарілі кодування, Git цього не забороняє. Однак, є кілька речей, які слід памʼятати.

git commit та git commit-tree видають попередження, якщо повідомлення журналу комітів, надане їм, не виглядає як коректний рядок UTF-8, окрім випадків, коли ви явно вкажете, що ваш проєкт використовує застаріле кодування. Це можна зробити, додавши i18n.commitEncoding у файл .git/config, ось так:
```
[i18n]
	commitEncoding = ISO-8859-1
```
Обʼєкти комітів, створені з використанням вищевказаного налаштування, записують значення i18n.commitEncoding у свій заголовок encoding. Це зроблено для того, щоб допомогти іншим користувачам, які переглядатимуть їх пізніше. Відсутність цього заголовка означає, що повідомлення журналу комітів закодоване в UTF-8.
git log, git show, git blame та інші команди переглядають заголовок encoding обʼєкта коміту та намагаються перекодувати повідомлення журналу в UTF-8, якщо не вказано інше. Ви можете вказати потрібне кодування виводу за допомогою i18n.logOutputEncoding у файлі .git/config, ось так:
```
[i18n]
	logOutputEncoding = ISO-8859-1
```
Якщо у вас немає цієї змінної конфігурації, замість неї використовується значення i18n.commitEncoding.

Зверніть увагу, що ми навмисно вирішили не перекодувати повідомлення журналу комітів, коли коміт робиться для примусового використання UTF-8 на рівні обʼєкта коміту, оскільки перекодування в UTF-8 не обовʼязково є оборотною операцією.

КОНФІГУРАЦІЯ

Дивіться git-config[1] для основних змінних та git-diff[1] для налаштувань, повʼязаних з генерацією diff.

format.pretty: Стандартне значення для параметра --format. (Див. розділ «Гарні формати» вище.) Стандартне значення — medium.
i18n.logOutputEncoding: Кодування, яке використовуватиметься під час відображення журналів. (Див. розділ «Обговорення» вище.) Зазвичай використовується значення i18n.commitEncoding, якщо встановлено, та UTF-8 в іншому випадку.

Все, що знаходиться вище цього рядка в цьому розділі, не включено до документації git-config[1]. Наступний вміст такий самий, як і той, що знаходиться там:

log.abbrevCommit

Якщо вказано true, команди git-log[1], git-show[1] та git-whatchanged[1] працюватимуть з параметром --abbrev-commit. Його можна замінити на --no-abbrev-commit.

log.date

Встановлює стандартний режим дати та часу для команди log. Встановлення значення для параметра log.date аналогічне використанню опції --date команди git log. Детальніше див. git-log[1].

Якщо для параметра форматування встановлено значення "auto:foo" і використовується pager, для форматування дати буде застосовано формат "foo". В іншому випадку буде застосовано формат "default".

log.decorate

Виводити назви ref усіх комітів, які показує команда log. Можливі значення:

short: префікси імен посилань refs/heads/, refs/tags/ та refs/remotes/ не виводяться.
full: виводиться повна назва посилання (включно з префіксом).
auto: якщо вивід йде в термінал, імена ref показуються так, ніби було вказано short, в іншому випадку імена ref не показуються.

Це те саме, що й опція --decorate команди git log.

log.initialDecorationSet

Зазвичай git log показує лише оформлення для певних відомих просторів імен ref. Якщо вказано «all», то всі refs показуються з оформленням.

log.excludeDecoration

Виключити вказані шаблони з оформлення журналу. Це аналогічно параметру командного рядка --decorate-refs-exclude, але значення цього параметра конфігурації може бути замінено параметром --decorate-refs.

log.diffMerges

Встановлює формат diff, який буде використовуватися при вказанні параметра --diff-merges=on. Детальніше див. --diff-merges у git-log[1]. Стандартним значенням є separate.

log.follow

Якщо встановлено значення true, команда git log буде працювати так, ніби було вказано опцію --follow, коли задано один <path>. Ця опція має ті самі обмеження, що й --follow, тобто її не можна використовувати для відстеження декількох файлів, і вона не працює належним чином у разі нелінійної історії.

log.graphColors

Список кольорів, розділених комами, які можна використовувати для виводу ліній історії в команді git log --graph.

log.showRoot

Якщо встановлено значення true, початковий коміт буде показаний як велика подія створення. Це еквівалентно порівнянню з порожнім деревом. Такі інструменти, як git-log[1] або git-whatchanged[1], які зазвичай приховують кореневий коміт, тепер будуть його показувати. Стандартне значення — true.

log.showSignature

Якщо встановлено значення true, то git-log[1], git-show[1] та git-whatchanged[1] будуть працювати з параметром --show-signature.

log.mailmap

Якщо встановлено значення true, то git-log[1], git-show[1] та git-whatchanged[1] будуть використовувати параметр --use-mailmap; в іншому випадку — --no-use-mailmap. Стандартне значення — true.

notes.mergeStrategy: Яку стратегію обʼєднання вибрати у якості стандартної під час розвʼязання конфліктів у нотатках. Може бути одним зі значень: manual, ours, theirs, union або cat_sort_uniq. Стандартним значенням є manual. Докладнішу інформацію про кожну стратегію див. у розділі «СТРАТЕГІЇ ОБ’ЄДНАННЯ НОТАТОК» документації git-notes[1].

Цю настройку можна замінити, передавши параметр --strategy у командному рядку git-notes[1].
notes.<name>.mergeStrategy: Яку стратегію злиття обрати під час злиття нотаток у refs/notes/<name>. Цей параметр замінює більш загальний параметр notes.mergeStrategy. Докладнішу інформацію про доступні стратегії див. у розділі «СТРАТЕГІЇ ЗЛИТТЯ НОТАТОК» в git-notes[1].
notes.displayRef: Який ref (або refs, якщо вказано загальний параметр або кілька разів), крім стандартного, заданого за допомогою core.notesRef або GIT_NOTES_REF, слід використовувати для зчитування приміток під час показу повідомлень про коміти за допомогою команд із сімейства git log.

Це налаштування можна замінити за допомогою змінної середовища GIT_NOTES_DISPLAY_REF, яка має містити список ref або glob, розділених двокрапкою.

Для посилань, яких не існує, буде видано попередження, але глобальний обʼєкт, який не відповідає жодному посиланню, буде проігнорований.

Це налаштування можна вимкнути за допомогою опції --no-notes у сімействі команд git-log[1] або за допомогою опції --notes=<ref>, яку підтримують ці команди.

Фактичне значення core.notesRef (яке, можливо, замінено GIT_NOTES_REF) також неявним чином додається до списку refs для показу.
notes.rewrite.<command>: Під час перезапису комітів за допомогою <команди> (наразі amend або rebase), якщо ця змінна має значення false, git не копіюватиме примітки з оригінального коміту до перезаписаного. Стандартне значення — true. Див. також notes.rewriteRef нижче.

Це налаштування можна замінити за допомогою змінної середовища GIT_NOTES_REWRITE_REF, яка має містити список refs або globs, розділених двокрапкою.
notes.rewriteMode: Під час копіювання приміток під час перезапису (див. опцію notes.rewrite.<command>) визначає, що робити, якщо цільовий коміт уже містить примітку. Може приймати значення overwrite, concatenate, cat_sort_uniq або ignore. Стандартним значенням є concatenate.

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

Ця змінна не має стандартного значення; щоб увімкнути перезапис приміток, її потрібно налаштувати. Встановіть для неї значення refs/notes/commits, щоб увімкнути перезапис стандартних приміток до комітів.

Це значення можна замінити за допомогою змінної середовища GIT_NOTES_REWRITE_REF. Детальніше про формат цієї змінної див. у розділі notes.rewrite.<command> вище.

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

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands