Git

git-log last updated in 2.51.1

НАЗВА

git-log - Показати журнали комітів

СИНОПСИС

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

ОПИС

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

Перерахувати коміти, доступні за посиланнями barent з заданого(их) коміту(ів), але виключити коміти, доступні з того(их), що вказані з символом ^ перед ними. За замовчуванням результат виводиться у зворотному хронологічному порядку.

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

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

$ 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`;; the ref name prefixes `refs/heads/`, `refs/tags/` and
	`refs/remotes/` are not printed.
`full`;; the full ref name (including prefix) is printed.
`auto`:: if the output is going to a terminal, the ref names
	are shown as if `short` were given, otherwise no ref names are
	shown.

Опція --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

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

--[no-]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> або назвою функції regex <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 обчислює заголовки патчів (див. «Визначення власного заголовка hunk» у 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=<шаблон>).

--grep-reflog=<pattern>

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

--grep=<pattern>

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

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

--all-match

Обмежте вивід комітів тими, що відповідають усім заданим --grep, замість тих, що відповідають хоча б одному.

--invert-grep

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

-i

--regexp-ignore-case

Зіставляє обмежувальні шаблони регулярних виразів без урахування регістру літер.

--basic-regexp

Вважайте обмежувальні шаблони простими регулярними виразами; це значення за замовчуванням.

-E

--extended-regexp

Вважайте обмежувальні шаблони розширеними регулярними виразами, а не базовими регулярними виразами за замовчуванням.

-F

--fixed-strings

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

-P

--perl-regexp

Вважайте обмежуючі шаблони Perl-сумісними регулярними виразами.

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

--remove-empty

Зупинитися, коли заданий шлях зникає з дерева.

--merges

Виводити лише коміти злиття. Це точно те саме, що й --min-parents=2.

--no-merges

Не виводьте коміти з більш ніж одним батьківським елементом. Це точно те саме, що й --max-parents=1.

--min-parents=<number>

--max-parents=<number>

--no-min-parents

--no-max-parents

Показувати лише коміти, які мають щонайменше (або максимум) певну кількість батьківських комітів. Зокрема, --max-parents=1 те саме, що --no-merges, --min-parents=2 те саме, що --merges. --max-parents=0 повертає всі кореневі коміти, а --min-parents=3 повертає всі злиття Octopus.

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

--first-parent

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

Ця опція також змінює формат різниці за замовчуванням для комітів злиття на first-parent, див. --diff-merges=first-parent для отримання детальної інформації.

--exclude-first-parent-only

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

--not

Змінює значення префікса ^ (або його відсутності) на протилежне для всіх наступних специфікаторів версій, аж до наступного --not. При використанні в командному рядку перед --stdin, версії, передані через stdin, не будуть піддані його впливу. І навпаки, при передачі через стандартний ввід, версії, передані в командному рядку, не будуть піддані його впливу.

--all

Зробіть вигляд, що всі посилання в refs/, разом з HEAD, перелічені в командному рядку як <commit>.

--branches[=<pattern>]

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

--tags[=<pattern>]

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

--remotes[=<pattern>]

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

--glob=<glob-pattern>

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

--exclude=<glob-pattern>

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

Наведені шаблони не повинні починатися з refs/heads, refs/tags або refs/remotes при застосуванні до --branches, --tags або --remotes відповідно, і вони повинні починатися з refs/ при застосуванні до --glob або --all. Якщо передбачається завершальна /*, її потрібно вказати явно.

--exclude-hidden=(fetch|receive|uploadpack)

Не включайте посилання, які можуть бути приховані командами git-fetch, git-receive-pack або git-upload-pack, звернувшись до відповідної конфігурації fetch.hideRefs, receive.hideRefs або uploadpack.hideRefs разом із transfer.hideRefs (див. git-config[1]). Цей параметр впливає на наступний параметр псевдопосилання --all або --glob та очищається після їх обробки.

--reflog

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

--alternate-refs

Зробіть вигляд, що всі об’єкти, згадані як поради альтернативних репозиторіїв, перелічені в командному рядку. Альтернативний репозиторій – це будь-який репозиторій, каталог об’єктів якого вказано в objects/info/alternates. Набір включених об’єктів можна змінити за допомогою core.alternateRefsCommand тощо. Див. git-config[1].

--single-worktree

За замовчуванням усі робочі дерева будуть перевірені наступними опціями, якщо їх більше одного (див. git-worktree[1]): --all, --reflog та --indexed-objects. Ця опція змушує їх перевіряти лише поточне робоче дерево.

--ignore-missing

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

--bisect

Зробіть вигляд, що посилання на погану бісекцію refs/bisect/bad було перераховано, а за нею слідувало --not, а в командному рядку — посилання на хорошу бісекцію refs/bisect/good-*.

--stdin

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

--cherry-mark

Подібно до --cherry-pick (див. нижче), але позначте еквівалентні коміти знаком =, а не пропускайте їх, а нееквівалентні — знаком +.

--cherry-pick

Пропускати будь-який коміт, який вносить ту саму зміну, що й інший коміт на «іншому боці», коли набір комітів обмежений симетричною різницею.

Наприклад, якщо у вас є дві гілки, A та B, звичайний спосіб перерахувати всі коміти лише з одного боку від них — це використовувати --left-right (див. приклад нижче в описі опції --left-right). Однак, це показує коміти, які були вибрані з іншої гілки (наприклад, “3rd on b” може бути вибраний з гілки A). З цією опцією такі пари комітів виключаються з виводу.

--left-only

--right-only

Перераховувати лише коміти з відповідного боку симетричної різниці, тобто лише ті, які будуть позначені < відповідно > за допомогою --left-right.

Наприклад, --cherry-pick --right-only A...B пропускає ті коміти з B, які знаходяться в A або є патч-еквівалентами коміту в A. Іншими словами, це перераховує + коміти з git cherry A B. Точніше, --cherry-pick --right-only --no-merges дає точний список.

--cherry

Синонім до --right-only --cherry-mark --no-merges; корисно для обмеження виводу коммітів на нашому боці та позначення тих, що були застосовані на іншому боці розгалуженої історії, за допомогою git log --cherry upstream...mybranch, подібно до git cherry upstream mybranch.

-g

--walk-reflogs

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

Якщо формат --pretty відрізняється від oneline та reference (з очевидних причин), це призводить до того, що вивід містить два додаткові рядки інформації, взятої з журналу посилань. Позначення журналу посилань у вивідних даних може відображатися як ref@{<Nth>} (де <Nth> — це зворотний хронологічний індекс у журналі посилань) або як ref@{<timestamp>} (з <timestamp> для цього запису), залежно від кількох правил:

Якщо початкова точка вказана як 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 як <шляхи>. Ми називатимемо коміти, що змінюють foo, !TREESAME, а решту TREESAME. (У різниці, відфільтрованій для foo, вони виглядають відповідно різними та рівними.)

Далі ми завжди будемо посилатися на ту саму історію прикладів, щоб проілюструвати відмінності між налаштуваннями спрощення. Ми припускаємо, що ви фільтруєте файл foo у цьому графі комітів:

	  .-A---M---N---O---P---Q
	 /     /   /   /   /   /
	I     B   C   D   E   Y
	 \   /   /   /   /   /
	  `-------------'   X

Горизонтальна лінія історії A---Q вважається першим батьківським елементом кожного злиття. Коміти такі:

I — це початковий коміт, в якому існує foo зі вмістом asdf, та файл quux зі вмістом quux. Початкові коміти порівнюються з порожнім деревом, тому I — це !TREESAME.
У A, foo містить лише foo.
B містить таку саму зміну, як і A. Його злиття M є тривіальним і, отже, є TREESAME для всіх батьківських об’єктів.
C не змінює foo, але його злиття N змінює його на foobar, тому воно не є TREESAME для жодного з батьківських об’єктів.
D встановлює foo в baz. Його злиття O поєднує рядки з N та D у foobarbaz; тобто воно не є TREESAME для жодного з батьківських елементів.
E змінює quux на xyzzy, а його злиття P об’єднує рядки в quux xyzzy. P перетворюється на TREESAME на O, але не на E.
X — це незалежний кореневий коміт, який додав новий файл side, а Y змінив його. Y — це TREESAME до X. Його злиття Q додало side до P, а Q — це TREESAME до P, але не до Y.

rev-list переглядає історію назад, включаючи або виключаючи коміти залежно від того, чи використовується --full-history та/або перезапис батьківських елементів (через --parents або --children). Доступні такі налаштування.

Режим за замовчуванням

Коміти включаються, якщо вони не є TREESAME для жодного з батьківських об’єктів (хоча це можна змінити, див. --sparse нижче). Якщо коміт був злиттям, і він був TREESAME для одного з батьківських об’єктів, слідкуйте лише за цим батьківським об’єктом. (Навіть якщо батьківських об’єктів TREESAME кілька, слідкуйте лише за одним з них.) В іншому випадку, слідкуйте за всіма батьківськими об’єктами.

Це призводить до:

	  .-A---N---O
	 /     /   /
	I---------D

Зверніть увагу, як правило слідування лише батьківському елементу TREESAME, якщо такий доступний, повністю виключило B з розгляду. C розглядався через N, але є TREESAME. Кореневі коміти порівнюються з порожнім деревом, тому I є !TREESAME.

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

--full-history без переписування батьків

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

	I  A  B  N  D  O  P  Q

M було виключено, оскільки воно є TREESAME для обох батьків. E, C та B були пройдені, але лише B було !TREESAME, тому інші не відображаються.

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

--full-history з переписуванням батьків

Звичайні коміти включаються лише якщо вони мають значення !TREESAME (хоча це можна змінити, див. --sparse нижче).

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

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

Порівняйте з --full-history без перезапису вище. Зверніть увагу, що E було видалено, оскільки воно є TREESAME, але батьківський список P було переписано, щоб містити батьківський I для E. Те саме сталося для C та N, а також X, Y та Q.

Окрім вищезазначених налаштувань, ви можете змінити, чи впливає TREESAME на включення:

--dense

Коміти, які пройдено, включаються, якщо вони не є TREESAME для жодного з батьківських об’єктів.

--sparse

Включаються всі пройдені коміти.

Зверніть увагу, що без --full-history це все одно спрощує злиття: якщо один з батьківських елементів є TREESAME, ми слідуємо лише за ним, тому інші сторони злиття ніколи не обходяться.

--simplify-merges

Спочатку побудуйте граф історії так само, як це робить --full-history з батьківським перезаписом (див. вище).

Потім спростіть кожен коміт C до його заміни C у фінальній історії відповідно до наступних правил:

Встановіть C на C.
Замініть кожного батьківського елемента P з ‘C’' на його спрощений ‘P’'. У процесі, видаліть батьківських елементів, які є предками інших батьківських елементів або кореневих елементів, що коміти TREESAME до порожнього дерева та видаліть дублікати, але будьте обережні, щоб ніколи не видаляти всіх батьківських елементів, до яких ми є TREESAME.
Якщо після цього перезапису батьківського елемента, ‘C’' є кореневим або злиттям-комітом (має нуль або >1 батьків), граничним комітом або !TREESAME, він залишається. В іншому випадку він замінюється своїм єдиним батьківським елементом.

Ефект цього найкраще продемонструвати шляхом порівняння з --full-history з перезаписом батьківських елементів. Приклад перетворюється на:

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

Зверніть увагу на основні відмінності між N, P та Q порівняно з --full-history:

З батьківського списку N було видалено I, оскільки він є предком іншого батьківського списку M. Тим не менш, N залишився, оскільки він є !TREESAME.
З батьківського списку P аналогічно було видалено I. P потім було видалено повністю, оскільки він мав одного батька та є TREESAME.
У батьківському списку Q Y було спрощено до X. X потім було видалено, оскільки він був коренем TREESAME. Q потім було повністю видалено, оскільки він мав одного батька і є TREESAME.

Існує ще один режим спрощення:

--ancestry-path[=<commit>]

Обмежити відображення комітів тими, що є предком <commit>, або тими, що є нащадком <commit>, або тими, що є самим <commit>.

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

	    D---E-------F
	   /     \       \
	  B---C---G---H---I---J
	 /                     \
	A-------K---------------L--M

Звичайна команда D..M обчислює набір комітів, які є предками M, але виключає ті, що є предками D. Це корисно, щоб побачити, що сталося з історією, що призвела до M з часів D, у сенсі "що має M такого, чого не існувало в D". Результатом у цьому прикладі будуть усі коміти, крім A та B (і самого D, звичайно).

Однак, коли ми хочемо з’ясувати, які коміти в M заражені помилкою, внесеною D, і потребують виправлення, ми можемо переглянути лише підмножину D..M, які насправді є нащадками D, тобто виключаючи C та K. Саме це робить опція --ancestry-path. Застосована до діапазону D..M, вона дає:

		E-------F
		 \       \
		  G---H---I---J
			       \
				L--M

Ми також можемо використовувати --ancestry-path=D замість --ancestry-path, що означає те саме, якщо застосувати його до діапазону D..M, але є більш чітким.

Якщо нас цікавить певна тема в цьому діапазоні та всі коміти, на які впливає ця тема, ми можемо переглянути лише підмножину D..M, які містять цю тему у своєму шляху походження. Отже, використання --ancestry-path=H D..M, наприклад, призведе до:

		E
		 \
	      C---G---H---I---J
			       \
				L--M

Тоді як --ancestry-path=K D..M призведе до

		K---------------L--M

Перш ніж обговорювати інший параметр, --show-pulls, нам потрібно створити новий приклад історії.

Поширена проблема, з якою стикаються користувачі під час перегляду спрощеної історії, полягає в тому, що коміт, про який вони знають, що змінив файл, якимось чином не відображається у спрощеній історії файлу. Давайте продемонструємо новий приклад і покажемо, як у цьому випадку працюють такі опції, як --full-history та --simplify-merges:

	  .-A---M-----C--N---O---P
	 /     / \  \  \/   /   /
	I     B   \  R-'`-Z'   /
	 \   /     \/         /
	  \ /      /\        /
	   `---X--'  `---Y--'

Для цього прикладу, припустимо, що I створив file.txt, який був змінений A, B та X різними способами. Коміти з одним батьківським файлом C, Z та Y не змінюють file.txt. Коміт злиття M був створений шляхом вирішення конфлікту злиття, щоб включити обидві зміни з A та B, і тому не є TREESAME для жодного з них. Однак коміт злиття R був створений шляхом ігнорування вмісту file.txt у M та взяття лише вмісту file.txt у X. Отже, R є TREESAME для X, але не M. Зрештою, природним рішенням злиття для створення N є взяття вмісту file.txt у R, тому N є TREESAME для R, але не для C. Коміти злиття O та P є TREESAME для своїх перших батьків, але не для своїх других батьків, Z та Y відповідно.

У режимі за замовчуванням, N та R мають батьківський елемент TREESAME, тому ці ребра обходяться, а інші ігноруються. Результуючий граф історії має такий вигляд:

	I---X

При використанні --full-history, Git проходить кожне ребро. Це виявить коміти A та B, а також коміти злиття M, а також покаже коміти злиття O та P. Після перезапису батьківських елементів результуючий граф буде таким:

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

Тут коміти злиття O та P створюють додатковий шум, оскільки вони фактично не внесли змін до file.txt. Вони лише об’єднали тему, яка базувалася на старішій версії file.txt. Це поширена проблема в репозиторіях, де багато учасників працюють паралельно та об’єднують свої тематичні гілки вздовж однієї магістралі: багато непов’язаних злиття відображаються в результатах --full-history.

При використанні опції --simplify-merges коміти O та P зникають з результатів. Це тому, що переписані другі батьки O та P доступні з їхніх перших батьків. Ці ребра видаляються, і тоді коміти виглядають як коміти з одним батьківським елементом, які є TREESAME для свого батька. Це також відбувається з комітом N, що призводить до наступного вигляду історії:

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

У цьому поданні ми бачимо всі важливі зміни для єдиного батьківського елемента з A, B та X. Ми також бачимо ретельно вирішене злиття M та не дуже ретельно вирішене злиття R. Зазвичай цієї інформації достатньо, щоб визначити, чому коміти A та B "зникли" з історії у поданні за замовчуванням. Однак, з таким підходом є кілька проблем.

Перша проблема — це продуктивність. На відміну від будь-якої попередньої опції, опція --simplify-merges вимагає перегляду всієї історії комітів, перш ніж повернути один результат. Це може ускладнити використання цієї опції для дуже великих репозиторіїв.

Друга проблема стосується аудиту. Коли багато учасників працюють над одним репозиторієм, важливо, які коміти злиття внесли зміни у важливу гілку. Проблемне злиття R вище, ймовірно, не є тим комітом злиття, який було використано для злиття у важливу гілку. Натомість, для злиття R та X у важливу гілку було використано злиття N. Цей коміт може містити інформацію про те, чому зміна X перевизначила зміни з A та B у своєму повідомленні коміту.

--show-pulls

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

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

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

Тут включено коміти злиття R та N, оскільки вони перенесли коміти X та R відповідно до базової гілки. Ці злиття є причиною того, що коміти A та B не відображаються в історії за замовчуванням.

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

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

Зверніть увагу, що оскільки M досяжний з R, ребро від N до M було спрощено. Однак, N все ще відображається в історії як важливий коміт, оскільки він "переніс" зміну R в головну гілку.

Опція --simplify-by-decoration дозволяє переглядати лише загальну картину топології історії, пропускаючи коміти, на які не посилаються теги. Коміти позначаються як !TREESAME (іншими словами, зберігаються після правил спрощення історії, описаних вище), якщо (1) на них посилаються теги, або (2) вони змінюють вміст шляхів, заданих у командному рядку. Усі інші коміти позначаються як TREESAME (підлягають видаленню за допомогою спрощення).

Порядок фіксації

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

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

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

Об’єкти Commit записують кодування символів, яке використовується для повідомлення журналу, у своєму заголовку кодування; цю опцію можна використовувати, щоб вказати команді перекодувати повідомлення журналу комітів у кодуванні, яке надає перевагу користувач. Для команд, які не є фахівцями з обробки даних, за замовчуванням використовується 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> використовуйте посилання (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 не використовується, усі гілки історії згладжуються, що може ускладнити визначення того, що два послідовні коміти не належать до лінійної гілки. У такому випадку ця опція встановлює бар’єр між ними. Якщо вказано <бар’єр>, то замість рядка за замовчуванням буде показано саме цей рядок.

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

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

full

commit <hash>
Author: <author>
Commit: <committer>

<title-line>

<повідомлення про повний фіксований запис (full-commit)>

fuller

commit <hash>
Author:     <author>
AuthorDate: <author-date>
Commit:     <committer>
CommitDate: <committer-date>

<title-line>

<повідомлення про повний фіксований запис (full-commit)>

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

email

Від <hash> <date>
Від: <author>
Дата: <author-date>
Суб'єкт: [PATCH] <title-line>

<повідомлення про повний фіксований запис (full-commit)>

mboxrd

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

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

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

Наприклад, «format:"Автором %h був %an, %ar%nНазва була >>%s<<%n"» виведе щось на кшталт цього:
```
Автором fe6e0ee був Junio C Hamano, 23 години тому
Назва була >>t4119: тест автообчислення -p<n> для традиційного введення різниці.<<
```
Заповнювачі:
- Заповнювачі, що розгортаються до одного літерала:
  
  %n
  
  newline
  
  %%
  
  a raw %
  
  %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) скороченої назви об’єкта, використовуйте <кількість> цифр або стільки цифр, скільки потрібно для формування унікальної назви об’єкта.

match=<pattern>: Розглядати лише теги, що відповідають заданому шаблону 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 хвилини назад}; формат відповідає правилам, описаним для опції -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

електронна адреса для ідентифікації повторного журналу

%gE

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

%gs

повторно заповнити суб’єкта

%(trailers[:<option>,...])
відобразити трейлери тіла, як їх інтерпретує git-interpret-trailers[1]. Рядок trailers може супроводжуватися двокрапкою та нулем або більше параметрами, розділеними комами. Якщо будь-який параметр вказано кілька разів, переважає останній вхід.
key=<ключ>: показувати лише трейлери з вказаним <ключ>. Зіставлення виконується без урахування регістру, а двокрапка в кінці є необов’язковою. Якщо опція вказана кілька разів, відображаються рядки трейлера, що відповідають будь-якому з ключів. Ця опція автоматично вмикає опцію only, щоб приховувати рядки, що не є трейлерами, у блоці трейлера. Якщо це небажано, її можна вимкнути за допомогою >. Наприклад, %(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 вставлятимуть порожній рядок, якщо ми не проходимо записи reflog (наприклад, за допомогою git log -g). Заповнювачі %d та %D використовуватимуть формат декорування "short", якщо --decorate ще не було вказано в командному рядку.





Логічні опції приймають необов’язкове значення [=<логічне-значення>]. Значення, що приймаються --type=bool git-config[1], такі як yes та off, також приймаються. Надання логічного параметра без =<значення> еквівалентно наданню його з =true.


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


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


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




tformat:

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



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

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



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



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



ФОРМАТУВАННЯ РІЗНИЦЬ


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


Зверніть увагу, що якщо явно не вказано один із варіантів --diff-merges (включаючи короткі опції -m, -c, --cc та --dd), коміти злиття не відображатимуть різницю, навіть якщо вибрано формат різниці, такий як --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 

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

  on 
  m 

Зробити так, щоб вивід diff для комітів злиття відображався у форматі за замовчуванням. Формат за замовчуванням можна змінити за допомогою змінної конфігурації log.diffMerges, значення за замовчуванням якої — separate.

  first-parent 
  1 

Показати повну різницю відносно першого батьківського елемента. Це той самий формат, який створює --patch для комітів без злиття.

  separate 

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

  combined 
  c 

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

  dense-combined 
  cc 

Подальше стиснення виводу, отриманого за допомогою --diff-merges=combined, шляхом пропускання нецікавих фрагментів, вміст яких у батьківських об’єктах має лише два варіанти, і результат злиття вибирає один з них без змін.

  remerge 
  r 

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






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


  --combined-all-paths 

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

  -U<n> 
  --unified=<n> 

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

  --output=<файл> 

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

  --output-indicator-new=<char> 
  --output-indicator-old=<char> 
  --output-indicator-context=<char> 

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

  --raw 

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

  --patch-with-raw 

Синонім до слова -p --raw.

  -t 

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

  --indent-heuristic 

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

  --no-indent-heuristic 

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

  --minimal 

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

  --patience 

Згенеруйте різницю за допомогою алгоритму "різниця терпіння".

  --histogram 

Згенеруйте різницю за допомогою алгоритму "різниця гістограми".

  --anchored=<text> 

Згенеруйте різницю за допомогою алгоритму "закріпленої різниці".

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


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


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

Виберіть алгоритм порівняння. Варіанти такі:




  default 
  myers 

Базовий алгоритм жадібного різниці. Наразі це алгоритм за замовчуванням.

  minimal 

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

  patience 

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

  histogram 

Цей алгоритм розширює алгоритм терпіння для «підтримки рідко зустрічаються поширених елементів».






Наприклад, якщо ви налаштували змінну 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 

Вивести стислий виклад розширеної інформації заголовка, такої як створення або видалення файлів ("new" або "gone", необов’язково +l, якщо це символічне посилання) та зміни режиму (+x або -x для додавання або видалення виконуваного біта відповідно) у diffstat. Інформація розміщується між частиною імені файлу та частиною графу. Має на увазі --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 

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

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


Без цієї опції шляхи з «незвичайними» символами взяті в лапки, як пояснено для змінної конфігурації 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 

Є синонімом слова «зебра». У майбутньому це може змінитися на більш розумний режим.

  plain 

Будь-який рядок, доданий в одному місці та видалений в іншому, буде забарвлений за допомогою color.diff.newMoved. Аналогічно, color.diff.oldMoved буде використано для видалених рядків, доданих деінде в різниці. Цей режим виявляє будь-який переміщений рядок, але він не дуже корисний під час перегляду, щоб визначити, чи блок коду був переміщений без перестановки.

  blocks 

Блоки переміщеного тексту довжиною щонайменше 20 буквено-цифрових символів виявляються жадібно. Виявлені блоки зафарбовуються кольором 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>, щоб визначити, що таке слово, замість того, щоб вважати словом рядки, що не є пробілами. Також мається на увазі --word-diff, якщо ця опція ще не була ввімкнена.

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


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


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


  --color-words[=<regex>] 

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

  --no-renames 

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

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

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


<файл_замовлення> аналізується наступним чином:






Пусті рядки ігноруються, тому їх можна використовувати як роздільники для зручності читання.


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


Кожен інший рядок містить один візерунок.






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


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

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

  -R 

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

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

Під час запуску з підкаталогу проєкту можна наказати програмі виключати зміни за межами каталогу та показувати шляхи відносно нього за допомогою цієї опції. Коли ви не перебуваєте в підкаталозі (наприклад, у чистому репозиторії), ви можете вказати, відносно якого підкаталогу робити вивід, вказавши <шлях> як аргумент. --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=<регулярний вираз> 

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

  --inter-hunk-context=<number> 

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

  -W 
  --function-context 

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

  --ext-diff 

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

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

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

  --dst-prefix=<prefix> 

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

  --no-prefix 

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

  --default-prefix 

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

  --line-prefix=<prefix> 

Додайте додатковий <префікс> до кожного рядка виводу.

  --ita-invisible-in-index 

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




Для більш детального пояснення цих поширених опцій див. також 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% означає, що жоден рядок зі старого файлу не потрапив до нового.


Рядок індексу містить імена блоб-об’єктів до та після зміни. <mode> додається, якщо режим файлу не змінюється; інакше окремі рядки вказують на старий та новий режими.



Шляхи з «незвичайними» символами взяті в лапки, як пояснено для змінної конфігурації 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] для отримання детальної інформації про те, як налаштувати це для певних мов.






Комбінований формат різниці


Будь-яка команда, що генерує різниці, може використовувати опцію -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 двох <tree-ish> і не використовуються комбінованим форматом 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 — це етап 2, також відомий як "наша версія", file2 — це етап 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 

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

  git log -p -m --first-parent 

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

  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] для налаштувань, пов’язаних з генерацією різниці.



  format.pretty 

Значення за замовчуванням для опції --format. (Див. «Гарні формати» вище.) За замовчуванням medium.

  i18n.logOutputEncoding 

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




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





Warning



Missing uk/config/log.adoc


See original version for this content.









Warning



Missing uk/config/notes.adoc


See original version for this content.








GIT


Частина набору 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

НАЗВА

СИНОПСИС

ОПИС

ОПЦІЇ

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

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

Порядок фіксації

Обхід об’єкта

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

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

ФОРМАТУВАННЯ РІЗНИЦЬ

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

Комбінований формат різниці

ПРИКЛАДИ

ОБГОВОРЕННЯ

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