Setup and Config
Getting and Creating Projects
Basic Snapshotting
Branching and Merging
Sharing and Updating Projects
Inspection and Comparison
Patching
Debugging
External Systems
Server Admin
Guides
- gitattributes
- Command-line interface conventions
- Everyday Git
- Frequently Asked Questions (FAQ)
- Glossary
- Hooks
- gitignore
- gitmodules
- Revisions
- Submodules
- Tutorial
- Workflows
- All guides...
Administration
Plumbing Commands
-
2.51.0
2025-08-18
- 2.50.1 no changes
-
2.50.0
2025-06-16
- 2.49.1 no changes
-
2.49.0
2025-03-14
- 2.48.1 → 2.48.2 no changes
-
2.48.0
2025-01-10
- 2.45.1 → 2.47.3 no changes
-
2.45.0
2024-04-29
- 2.43.3 → 2.44.4 no changes
-
2.43.2
2024-02-13
- 2.43.1 no changes
-
2.43.0
2023-11-20
- 2.42.1 → 2.42.4 no changes
-
2.42.0
2023-08-21
- 2.41.1 → 2.41.3 no changes
-
2.41.0
2023-06-01
- 2.40.1 → 2.40.4 no changes
-
2.40.0
2023-03-12
- 2.39.1 → 2.39.5 no changes
-
2.39.0
2022-12-12
- 2.38.1 → 2.38.5 no changes
-
2.38.0
2022-10-02
- 2.37.1 → 2.37.7 no changes
-
2.37.0
2022-06-27
- 2.36.1 → 2.36.6 no changes
-
2.36.0
2022-04-18
- 2.35.1 → 2.35.8 no changes
-
2.35.0
2022-01-24
- 2.33.3 → 2.34.8 no changes
-
2.33.2
2022-03-23
-
2.33.1
2021-10-12
-
2.33.0
2021-08-16
- 2.32.1 → 2.32.7 no changes
-
2.32.0
2021-06-06
- 2.31.1 → 2.31.8 no changes
-
2.31.0
2021-03-15
- 2.30.1 → 2.30.9 no changes
-
2.30.0
2020-12-27
- 2.29.1 → 2.29.3 no changes
-
2.29.0
2020-10-19
- 2.28.1 no changes
-
2.28.0
2020-07-27
- 2.27.1 no changes
-
2.27.0
2020-06-01
- 2.26.1 → 2.26.3 no changes
-
2.26.0
2020-03-22
- 2.25.1 → 2.25.5 no changes
-
2.25.0
2020-01-13
- 2.24.1 → 2.24.4 no changes
-
2.24.0
2019-11-04
- 2.23.1 → 2.23.4 no changes
-
2.23.0
2019-08-16
- 2.22.1 → 2.22.5 no changes
-
2.22.0
2019-06-07
- 2.21.1 → 2.21.4 no changes
-
2.21.0
2019-02-24
- 2.20.1 → 2.20.5 no changes
-
2.20.0
2018-12-09
- 2.19.3 → 2.19.6 no changes
-
2.19.2
2018-11-21
- 2.17.1 → 2.19.1 no changes
-
2.17.0
2018-04-02
-
2.16.6
2019-12-06
-
2.15.4
2019-12-06
-
2.14.6
2019-12-06
-
2.13.7
2018-05-22
-
2.12.5
2017-09-22
-
2.11.4
2017-09-22
-
2.10.5
2017-09-22
-
2.9.5
2017-07-30
-
2.8.6
2017-07-30
-
2.7.6
2017-07-30
-
2.6.7
2017-05-05
-
2.5.6
2017-05-05
-
2.4.12
2017-05-05
-
2.3.10
2015-09-28
-
2.2.3
2015-09-04
-
2.1.4
2014-12-17
-
2.0.5
2014-12-17
ОПИС
Перерахувати коміти, доступні за посиланнями barent
з заданого(их) коміту(ів), але виключити коміти, доступні з того(их), що вказані з символом ^ перед ними. За замовчуванням результат виводиться у зворотному хронологічному порядку.
Ви можете розглядати це як операцію з набором. Коміти, досяжні з будь-якого з комітів, заданих у командному рядку, формують набір, а потім коміти, досяжні з будь-якого з тих, що задані з ^ попереду, віднімаються з цього набору. Решта комітів - це те, що виводиться у виводі команди. Різні інші опції та параметри шляхів можна використовувати для подальшого обмеження результату.
Таким чином, наступна команда:
$ git rev-list foo bar ^baz
означає «перерахувати всі коміти, які доступні з foo або bar, але не з baz».
Спеціальне позначення "<commit1>..
<commit2>" може використовуватися як скорочений запис для "^
<commit1> <commit2>". Наприклад, будь-який з наступних варіантів може використовуватися як взаємозамінний:
$ git rev-list origin..HEAD $ git rev-list HEAD ^origin
Ще одне спеціальне позначення — "<commit1>...
<commit2>", яке корисне для злиття. Результуючий набір комітів — це симетрична різниця між двома операндами. Наступні дві команди еквівалентні:
$ git rev-list A B --not $(git merge-base --all A B) $ git rev-list A...B
«rev-list» — це важлива команда Git, оскільки вона надає можливість створювати та переглядати графи предків комітів. З цієї причини вона має багато різних опцій, які дозволяють використовувати її такими різними командами, як «git bisect» та «git repack».
ОПЦІЇ
Обмеження комітів
Окрім визначення діапазону комітів, які слід перерахувати, за допомогою спеціальних позначень, пояснених в описі, можуть бути застосовані додаткові обмеження кількості комітів.
Використання більшої кількості опцій зазвичай ще більше обмежує вивід (наприклад, --since=
<date1> обмежує коміти, новіші за <date1>, а використання з --grep=
<pattern> ще більше обмежує коміти, повідомлення журналу яких містить рядок, що відповідає <pattern>), якщо не зазначено інше.
Зверніть увагу, що ці параметри застосовуються перед упорядкуванням комітів та параметрами форматування, такими як --reverse
.
-
-
<number> -
-n
<number> -
--max-count=
<number> -
Обмежити вивід до <number> комітів.
-
--skip=
<number> -
Пропустити <number> комітів перед початком відображення виводу коміта.
-
--since=
<date> -
--after=
<date> -
Показати коміти, новіші за <date>.
-
--since-as-filter=
<date> -
Показати всі коміти, новіші за <date>. Це відвідує всі коміти в діапазоні, а не зупиняється на першому коміті, який старший за <date>.
-
--until=
<date> -
--before=
<date> -
Показати коміти, старші за <date>.
-
--max-age=
<timestamp> -
--min-age=
<timestamp> -
Обмежити вивід комітів заданим часовим діапазоном.
-
--author=
<pattern> -
--committer=
<pattern> -
Обмежте виведення комітів тими, у яких заголовки автора/комітера відповідають регулярному виразу <шаблон>. Якщо є більше одного
--author=
<шаблон>, вибираються коміти, автор яких відповідає будь-якому з <шаблон> (аналогічно для кількох--committer=
<шаблон>). -
--grep-reflog=
<pattern> -
Обмежте вивід комітів тими, у яких записи reflog відповідають регулярному виразу <pattern>. Якщо
--grep-reflog
використовується більше одного шаблону, вибираються коміти, повідомлення reflog яких відповідає будь-якому з заданих шаблонів. Використання цієї опції є помилкою, якщо не використовується--walk-reflogs
. -
--grep=
<pattern> -
Обмежте вивід комітів тими, у яких повідомлення журналу відповідає регулярному виразу <шаблон>. Якщо є більше одного
--grep=
<шаблон>, вибираються коміти, повідомлення яких відповідає будь-якому з <шаблон> (але див.--all-match
). -
--all-match
-
Обмежте вивід комітів тими, що відповідають усім заданим
--grep
, замість тих, що відповідають хоча б одному. -
--invert-grep
-
Обмежте вивід комітів тими, у яких повідомлення журналу не відповідає <шаблон>, зазначеному за допомогою
--grep=
<шаблон>. -
-i
-
--regexp-ignore-case
-
Зіставляє обмежувальні шаблони регулярних виразів без урахування регістру літер.
-
--basic-regexp
-
Вважайте обмежувальні шаблони простими регулярними виразами; це значення за замовчуванням.
-
-E
-
--extended-regexp
-
Вважайте обмежувальні шаблони розширеними регулярними виразами, а не базовими регулярними виразами за замовчуванням.
-
-F
-
--fixed-strings
-
Вважайте обмежувальні шаблони фіксованими рядками (не інтерпретуйте шаблон як регулярний вираз).
-
-P
-
--perl-regexp
-
Вважайте обмежуючі шаблони Perl-сумісними регулярними виразами.
Підтримка цих типів регулярних виразів є необов’язковою залежністю під час компіляції. Якщо Git не було скомпільовано з їх підтримкою, надання цієї опції призведе до його завершення роботи.
-
--remove-empty
-
Зупинитися, коли заданий шлях зникає з дерева.
-
--merges
-
Виводити лише коміти злиття. Це точно те саме, що й
--min-parents=2
. -
--no-merges
-
Не виводьте коміти з більш ніж одним батьківським елементом. Це точно те саме, що й
--max-parents=1
. -
--min-parents=
<number> -
--max-parents=
<number> -
--no-min-parents
-
--no-max-parents
-
Показувати лише коміти, які мають щонайменше (або максимум) певну кількість батьківських комітів. Зокрема,
--max-parents=1
те саме, що--no-merges
,--min-parents=2
те саме, що--merges
.--max-parents=0
повертає всі кореневі коміти, а--min-parents=3
повертає всі злиття Octopus.--no-min-parents
та--no-max-parents
знову скидають ці обмеження (до нульового значення). Еквівалентними формами є--min-parents=0
(будь-який коміт має 0 або більше батьків) та--max-parents=-1
(від’ємні числа означають відсутність верхньої межі). -
--first-parent
-
Під час пошуку комітів для включення, слідкуйте лише за першим батьківським комітом після перегляду коміту злиття. Ця опція може дати кращий огляд еволюції певної тематичної гілки, оскільки злиття в тематичну гілку, як правило, полягає лише в адаптації до оновлень основної версії, і ця опція дозволяє ігнорувати окремі коміти, що додаються до вашої історії в результаті такого злиття.
-
--exclude-first-parent-only
-
Під час пошуку комітів для виключення (за допомогою ^) слідкуйте лише за першим батьківським комітом після виявлення коміту злиття. Це можна використовувати для пошуку набору змін у тематичній гілці з точки, де вона відійшла від віддаленої гілки, враховуючи, що довільні злиття можуть бути дійсними змінами тематичної гілки.
-
--not
-
Змінює значення префікса ^ (або його відсутності) на протилежне для всіх наступних специфікаторів версій, аж до наступного
--not
. При використанні в командному рядку перед --stdin, версії, передані через stdin, не будуть піддані його впливу. І навпаки, при передачі через стандартний ввід, версії, передані в командному рядку, не будуть піддані його впливу. -
--all
-
Зробіть вигляд, що всі посилання в
refs/
, разом зHEAD
, перелічені в командному рядку як <commit>. -
--branches
[=
<pattern>] -
Зробіть вигляд, ніби всі посилання в
refs/heads
перелічені в командному рядку як <commit>. Якщо задано <pattern>, обмежте гілки тими, що відповідають заданому глобусу оболонки. Якщо <pattern> не містить ?, * або [, мається на увазі /* в кінці. -
--tags
[=
<pattern>] -
Зробіть вигляд, ніби всі посилання в
refs/tags
перелічені в командному рядку як <commit>. Якщо задано <pattern>, обмежте теги тими, що відповідають заданому глобусу оболонки. Якщо у шаблоні відсутні ?, * або [, мається на увазі /* в кінці. -
--remotes
[=
<pattern>] -
Зробіть вигляд, що всі посилання в
refs/remotes
перелічені в командному рядку як <commit>. Якщо задано <pattern>, обмежте гілки віддаленого відстеження тими, що відповідають заданому глобусу оболонки. Якщо у шаблоні відсутні ?, * або [, мається на увазі /* в кінці. -
--glob=
<glob-pattern> -
Зробіть вигляд, що всі посилання, що відповідають глобальному шаблону оболонки <глоб-шаблон>, перелічені в командному рядку як <комміт>. Початковий refs/ автоматично додається на початку, якщо відсутній. Якщо у шаблоні відсутні ?, * або [, мається на увазі /* в кінці.
-
--exclude=
<glob-pattern> -
Не включайте посилання, що відповідають <glob-pattern>, які наступні
--all
,--branches
,--tags
,--remotes
або--glob
враховували б. Повторення цієї опції накопичують шаблони виключень до наступної опції--all
,--branches
,--tags
,--remotes
або--glob
(інші опції або аргументи не очищують накопичені шаблони).Наведені шаблони не повинні починатися з
refs/heads
,refs/tags
абоrefs/remotes
при застосуванні до--branches
,--tags
або--remotes
відповідно, і вони повинні починатися зrefs/
при застосуванні до--glob
або--all
. Якщо передбачається завершальна /*, її потрібно вказати явно. -
Не включайте посилання, які можуть бути приховані командами
git-fetch
,git-receive-pack
абоgit-upload-pack
, звернувшись до відповідної конфігураціїfetch.hideRefs
,receive.hideRefs
абоuploadpack.hideRefs
разом ізtransfer.hideRefs
(див. git-config[1]). Цей параметр впливає на наступний параметр псевдопосилання--all
або--glob
та очищається після їх обробки. -
--reflog
-
Зробіть вигляд, що всі об’єкти, згадані в reflogs, перелічені в командному рядку як <commit>.
-
--alternate-refs
-
Зробіть вигляд, що всі об’єкти, згадані як поради альтернативних репозиторіїв, перелічені в командному рядку. Альтернативний репозиторій – це будь-який репозиторій, каталог об’єктів якого вказано в
objects/info/alternates
. Набір включених об’єктів можна змінити за допомогоюcore.alternateRefsCommand
тощо. Див. git-config[1]. -
--single-worktree
-
За замовчуванням усі робочі дерева будуть перевірені наступними опціями, якщо їх більше одного (див. git-worktree[1]):
--all
,--reflog
та--indexed-objects
. Ця опція змушує їх перевіряти лише поточне робоче дерево. -
--ignore-missing
-
Побачивши недійсне ім’я об’єкта у вхідних даних, зробіть вигляд, що неправильне ім’я не було вказано.
-
--stdin
-
Окрім отримання аргументів з командного рядка, їх також можна зчитувати зі стандартного вводу. Це дозволяє зчитувати коміти та псевдо-опції, такі як
--all
та--glob=
. Коли бачиться роздільник--
, наступний ввід обробляється як шлях і використовується для обмеження результату. Прапорці, такі як--not
, які зчитуються через стандартний ввід, враховуються лише для аргументів, переданих таким самим чином, і не впливатимуть на будь-які наступні аргументи командного рядка. -
--quiet
-
Не виводьте нічого на стандартний вивід. Ця форма в першу чергу призначена для того, щоб викликатий стороні вдалося перевірити статус виходу, щоб побачити, чи повноцінно підключено діапазон об’єктів (чи ні). Це швидше, ніж перенаправлення stdout на
/dev/null
, оскільки вивід не потрібно форматувати. -
--disk-usage
-
--disk-usage=human
-
Придушити звичайний вивід; натомість вивести суму байтів, використаних для зберігання на диску вибраними комітами або об’єктами. Це еквівалентно передачі виводу в
git
cat-file
--batch-check='%
(objectsize:disk
), за винятком того, що це працює набагато швидше (особливо з--use-bitmap-index
). Дивіться розділCAVEATS
у git-cat-file[1] для обмежень того, що означає "сховище на диску". З необов’язковим значеннямhuman
розмір сховища на диску відображається у вигляді рядка, який читається людиною (наприклад, 12,24 Кб, 3,50 Мб). -
--cherry-mark
-
Подібно до
--cherry-pick
(див. нижче), але позначте еквівалентні коміти знаком=
, а не пропускайте їх, а нееквівалентні — знаком+
. -
--cherry-pick
-
Пропускати будь-який коміт, який вносить ту саму зміну, що й інший коміт на «іншому боці», коли набір комітів обмежений симетричною різницею.
Наприклад, якщо у вас є дві гілки,
A
таB
, звичайний спосіб перерахувати всі коміти лише з одного боку від них — це використовувати--left-right
(див. приклад нижче в описі опції--left-right
). Однак, це показує коміти, які були вибрані з іншої гілки (наприклад, “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
-
Вивести виключені граничні коміти. Граничні коміти мають префікс
-
. -
--use-bitmap-index
-
Спробуйте пришвидшити перехід за допомогою індексу растрового зображення пакету (якщо такий доступний). Зверніть увагу, що під час переходу з
--objects
, дерева та блоби не матимуть пов’язаного шляху, що виводиться. -
--progress=
<header> -
Показувати звіти про хід виконання на stderr під час розгляду об’єктів. Текст <header> буде виведено з кожним оновленням прогресу.
-
-z
-
Замість розділення символами нового рядка, кожен виведений об’єкт та супутні йому метадані розділяються за допомогою NUL-байтів. Вивід виводиться у такому вигляді:
<OID> NUL [<token>=<value> NUL]...
Додаткові метадані об’єкта, такі як шляхи до об’єктів або граничні об’єкти, друкуються за допомогою форми <токен>
=
<значення>. Значення токенів друкуються як є без будь-якого кодування/скорочення. Запис OID ніколи не містить символу = і тому використовується для сигналізації початку нового запису об’єкта. Приклади:<OID> NUL <OID> NUL path=<path> NUL <OID> NUL boundary=yes NUL <OID> NUL missing=yes NUL [<token>=<value> NUL]...
Цей режим сумісний лише з параметрами виводу
--objects
,--boundary
та--missing
.
Спрощення історії
Іноді вас цікавлять лише частини історії, наприклад, коміти, що змінюють певний <path>. Але є дві частини «Спрощення історії», одна частина — це вибір комітів, а інша — як це зробити, оскільки існують різні стратегії спрощення історії.
Наступні опції вибирають коміти, які будуть показані:
Зверніть увагу, що додаткові коміти можуть бути показані для надання змістовної історії.
На спосіб виконання спрощення впливають такі параметри:
-
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 (підлягають видаленню за допомогою спрощення).
Помічники з бісекції
-
--bisect
-
Обмежити вивід одним об’єктом коміту, який приблизно знаходиться посередині між включеними та виключеними комітами. Зверніть увагу, що погане посилання на бісекцію
refs/bisect/bad
додається до включених комітів (якщо воно існує), а хороші посилання на бісекціюrefs/bisect/good-*
додаються до виключених комітів (якщо вони існують). Таким чином, припустимо, що вrefs/bisect/
немає посилань, якщо$ git rev-list --bisect foo ^bar ^baz
виводить «середню точку», вивід двох команд
$ git rev-list foo ^midpoint $ git rev-list midpoint ^bar ^baz
матиме приблизно таку ж довжину. Пошук зміни, яка вводить регресію, таким чином зводиться до бінарного пошуку: багаторазово генерувати та тестувати нові «середні точки», доки ланцюжок комітів не досягне довжини одиниці.
-
--bisect-vars
-
Це обчислює те саме, що й
--bisect
, за винятком того, що посилання вrefs/bisect/
не використовуються, і за винятком того, що це виводить текст, готовий до оцінки оболонкою. Ці рядки присвоїть назву середньої ревізії зміннійbisect_rev
, а очікувану кількість комітів, які будуть перевірені після перевіркиbisect_rev
, зміннійbisect_nr
, очікувану кількість комітів, які будуть перевірені, якщоbisect_rev
виявиться хорошим,bisect_good
, очікувану кількість комітів, які будуть перевірені, якщоbisect_rev
виявиться поганим,bisect_bad
, та кількість комітів, які ми зараз ділимо,bisect_all
. -
--bisect-all
-
Це виводить усі об’єкти комітів між включеними та виключеними комітами, упорядковані за їхньою відстанню до включених та виключених комітів. Посилання в
refs/bisect/
не використовуються. Найдальше від них відображається першим. (Це єдине, що відображається за допомогою--bisect
.)Це корисно, оскільки дозволяє легко вибрати хороший коміт для тестування, коли ви хочете уникнути тестування деяких із них з певної причини (наприклад, вони можуть не компілюватися).
Цю опцію можна використовувати разом з
--bisect-vars
, у цьому випадку після всіх відсортованих об’єктів комітів буде той самий текст, як якби--bisect-vars
використовувався окремо.
Порядок фіксації
За замовчуванням коміти відображаються у зворотному хронологічному порядку.
-
--date-order
-
Не показувати батьківських об’єктів, поки не будуть показані всі дочірні об’єкти, але в іншому випадку показувати коміти в порядку позначок часу комітів.
-
--author-date-order
-
Не показувати батьківських об’єктів, перш ніж будуть показані всі його дочірні об’єкти, але в іншому випадку показувати коміти в порядку позначення часу автора.
-
--topo-order
-
Не показувати батьківських об’єктів, поки не будуть показані всі їхні дочірні об’єкти, та уникати показу комітів у кількох переплетених рядках історії.
Наприклад, у такій історії комітів:
---1----2----4----7 \ \ 3----5----6----8---
де числа позначають порядок позначок часу комітів,
git
rev-list
та друзі з--date-order
показують коміти в порядку позначок часу: 8 7 6 5 4 3 2 1.З
--topo-order
вони б показали 8 6 5 3 7 4 2 1 (або 8 7 4 2 6 5 3 1); деякі старіші коміти показуються перед новішими, щоб уникнути показу комітів з двох паралельних треків розробки разом. -
--reverse
-
Вивести вибрані коміти для відображення (див. розділ «Обмеження комітів» вище) у зворотному порядку. Не можна поєднувати з
--walk-reflogs
.
Обхід об’єкта
Ці опції здебільшого призначені для пакування репозиторіїв Git.
-
--objects
-
Вивести ідентифікатори об’єктів будь-якого об’єкта, на який посилаються перелічені коміти.
--objects
foo
^bar
таким чином означає "надіслати мені всі ідентифікатори об’єктів, які мені потрібно завантажити, якщо в мене є об’єкт комітуbar
, але немаєfoo
". Див. також--object-names
нижче. -
--in-commit-order
-
Вивести ідентифікатори дерев та блобів у порядку комітів. Ідентифікатори дерев та блобів виводяться після першого посилання на них у коміті.
-
--objects-edge
-
Подібно до
--objects
, але також виводить ідентифікатори виключених комітів з префіксом "-
". Це використовується git-pack-objects[1] для створення "тонкого" пакету, який записує об’єкти у дельтифікованій формі на основі об’єктів, що містяться в цих виключених комітах, для зменшення мережевого трафіку. -
--objects-edge-aggressive
-
Подібно до
--objects-edge
, але намагається знайти виключені коміти ціною збільшення часу. Це використовується замість--objects-edge
для створення «тонких» пакетів для поверхневих репозиторіїв. -
--indexed-objects
-
Зробіть вигляд, що всі дерева та блоби, що використовуються індексом, перелічені в командному рядку. Зверніть увагу, що ви, ймовірно, також захочете використовувати
--objects
. -
--unpacked
-
Корисно лише з
--objects
; вивести ідентифікатори об’єктів, які не входять до пакетів. -
--object-names
-
Корисно лише з
--objects
; вивести назви знайдених ідентифікаторів об’єктів. Це поведінка за замовчуванням. Зверніть увагу, що "ім’я" кожного об’єкта неоднозначне і здебільшого призначене як підказка для пакування об’єктів. Зокрема: не розрізняється назва тегів, дерев і блобів; назви шляхів можна змінювати, щоб видалити символи нового рядка; і якщо об’єкт з’являється кілька разів з різними назвами, відображається лише одна назва. -
--no-object-names
-
Корисно лише з
--objects
; не виводить назви знайдених ідентифікаторів об’єктів. Це інвертує--object-names
. Цей прапорець дозволяє легше розбирати вивід за допомогою команд, таких як git-cat-file[1]. -
--filter=
<filter-spec> -
Корисно лише з одним із
--objects*
; пропускає об’єкти (зазвичай блоби) зі списку друкованих об’єктів. <специфікація-фільтра> може бути одним із наступних:Форма
--filter=blob:none
пропускає всі блоби.Форма
--filter=blob:limit=
<n>[kmg
] пропускає блоби розміром щонайменше <n> байтів або одиниць. <n> може дорівнювати нулю. Суфіксиk
,m
таg
можна використовувати для найменування одиниць у KiB, MiB або GiB. Наприклад,blob:limit=1k
те саме, що й blob:limit=1024.Форма
--filter=object:type=
(tag
|commit
|tree
|blob
) пропускає всі об’єкти, які не належать до запитуваного типу.Форма
--filter=sparse:oid=
<blob-ish> використовує специфікацію розрідженого отримання, що міститься в блобі (або блоб-виразі) <blob-ish>, щоб пропустити блоби, які не потрібні для розрідженого отримання на запитуваних посиланнях.Форма
--filter=tree:
<depth> пропускає всі блоби та дерева, глибина яких від кореневого дерева дорівнює >= <depth> (мінімальна глибина, якщо об’єкт розташований на кількох глибинах у пройдених коммітах). <depth>=0 не включатиме жодних дерев або блобів, якщо вони явно не включені в командному рядку (або стандартному вводі, коли використовується--stdin
). <depth>=1 включатиме лише дерево та блоби, на які безпосередньо посилається коміт, досягнутий з <commit> або явно заданого об’єкта. <depth>=2 подібна до <depth>=1, але також включає дерева та блоби, на один рівень віддалені від явно заданого коміту або дерева.Зверніть увагу, що форму
--filter=sparse:path=
<шлях>, яка хоче читати з довільного шляху у файловій системі, було видалено з міркувань безпеки.Для об’єднання фільтрів можна вказати кілька прапорців
--filter=
. Включаються лише об’єкти, які приймаються кожним фільтром.Форму
--filter=combine:
<filter1>+
<filter2>+...
<filterN> також можна використовувати для об’єднання кількох фільтрів, але це складніше, ніж просто повторювати прапорець--filter
, і зазвичай це не потрібно. Фільтри об’єднуються за допомогою +, а окремі фільтри мають %-кодування (тобто URL-кодування). Окрім символів + та %, наступні символи зарезервовані та також мають бути закодовані: ~!@#$^&*()[]{}\;",<>?'` а також усі символи з кодом ASCII <=0x20
, включаючи пробіл та символ нового рядка.Також можна закодувати інші довільні символи. Наприклад,
combine:tree:3+blob:none
таcombine:tree%3A3+blob%3Anone
є еквівалентними. -
--no-filter
-
Вимкніть будь-який попередній аргумент
--filter=
. -
--filter-provided-objects
-
Фільтрувати список явно заданих об’єктів, які в іншому випадку завжди друкувалися б, навіть якщо б вони не відповідали жодному з фільтрів. Корисно лише з
--filter=
. -
--filter-print-omitted
-
Корисно лише з
--filter=
; друкує список об’єктів, пропущених фільтром. Ідентифікатори об’єктів починаються з символу “~”. -
--missing=
<missing-action> -
Опція налагодження, яка допоможе в майбутній розробці "часткового клонування". Ця опція визначає, як обробляються відсутні об’єкти.
Форма
--missing=error
вимагає, щоб список переглядів зупинився з помилкою, якщо виявлено відсутній об’єкт. Це дія за замовчуванням.Форма
--missing=allow-any
дозволить продовжити обхід об’єкта, якщо буде виявлено відсутній об’єкт. Відсутні об’єкти будуть непомітно пропущені з результатів.Форма
--missing=allow-promisor
подібна доallow-any
, але дозволить продовження обходу об’єктів лише для ОЧІКУВАНИХ відсутніх об’єктів promisor. Неочікувано відсутні об’єкти викличуть помилку.Форма
--missing=print
подібна доallow-any
, але також виведе список відсутніх об’єктів. Ідентифікатори об’єктів починаються з символу “?”.Форма
--missing=print-info
подібна доprint
, але також виведе додаткову інформацію про відсутній об’єкт, виведену з об’єкта, що його містить. Вся інформація виводиться в одному рядку з ідентифікатором відсутнього об’єкта у формі: ?<oid> [<токен>=<значення>].... Пари <токен>=
<значення>, що містять додаткову інформацію, відокремлюються одна від одної за допомогою SP. Значення кодується специфічним для токена способом, але SP або LF, що містяться в значенні, завжди мають бути представлені таким чином, щоб результуюче закодоване значення не мало жодного з цих двох проблемних байтів. Кожен <токен>=
<значення> може бути одним із наступних:-
path=
<шлях> показує шлях до відсутнього об’єкта, виведений з об’єкта-містка. Шлях, що містить SP або спеціальні символи, за потреби береться в подвійні лапки у стилі C. -
type=
<тип> показує тип відсутнього об’єкта, виведений з об’єкта, який його містить.
Якщо деякі підказки, передані під час обходу, відсутні, вони також вважатимуться відсутніми, і обхід їх проігнорує. Однак, якщо нам не вдасться отримати їхній ідентифікатор об’єкта, буде викликана помилка.
-
-
--exclude-promisor-objects
-
(Тільки для внутрішнього використання.) Попередня фільтрація обходу об’єкта на межі промісора. Використовується з частковим клонуванням. Це сильніше, ніж
--missing=allow-promisor
, оскільки обмежує обхід, а не просто заглушує помилки про відсутні об’єкти. -
--no-walk
[=
(sorted
|unsorted
)] -
Показувати лише задані коміти, але не проходити через їхніх предків. Це не має ефекту, якщо вказано діапазон. Якщо вказано аргумент
unsorted
, коміти відображаються в порядку, в якому вони були введені в командному рядку. В іншому випадку (якщоsorted
або аргумент не вказано), коміти відображаються у зворотному хронологічному порядку за часом коміту. Не можна поєднувати з--graph
. -
--do-walk
-
Замінює попередній
--no-walk
.
Форматування комітів
Використовуючи ці опції, git-rev-list[1] працюватиме подібно до більш спеціалізованої родини інструментів для ведення журналу комітів: git-log[1], git-show[1], і git-whatchanged[1].
-
--pretty
[=
<format>] -
--format=
<format> -
Вивести вміст журналів комітів у заданому форматі, де <format> може бути одним із
oneline
,short
,medium
,full
,fuller
,reference
,email
,raw
,format:
<string> таtformat:
<string>. Коли <format> не є жодним із перерахованих вище та містить%
<placeholder>, це діє так, ніби було задано--pretty=tformat:
<format>.Див. розділ «ГАРНІ ФОРМАТИ» для отримання додаткової інформації щодо кожного формату. Якщо частину
=
<формат> пропустити, за замовчуванням використовується значення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
). -
--show-signature
-
Перевірте валідність підписаного об’єкта коміту, передавши підпис до
gpg
--verify
та покажіть результат.
-
--relative-date
-
Синонім до
--date=relative
. -
--date=
<format> -
Діє лише для дат, відображених у форматі, зрозумілому для людини, наприклад, при використанні
--pretty
. Змінна конфігураціїlog.date
встановлює значення за замовчуванням для опції--date
команди log. За замовчуванням дати відображаються в оригінальному часовому поясі (або комітера, або автора). Якщо до формату додається-local
(наприклад,iso-local
), замість цього використовується локальний часовий пояс користувача.--date=relative
показує дати відносно поточного часу, наприклад, “2 години тому”. Опція-local
не має жодного ефекту для--date=relative
.--date=local
є псевдонімом для--date=default-local
.--date=iso
(або--date=iso8601
) показує позначки часу у форматі, подібному до ISO 8601. Відмінності від суворого формату ISO 8601:-
пробіл замість роздільника дати/часу
T
-
простір між часом і часовим поясом
-
без двокрапки між годинами та хвилинами часового поясу
--date=iso-strict
(або--date=iso8601-strict
) показує позначки часу у суворому форматі ISO 8601.--date=rfc
(або--date=rfc2822
) показує позначки часу у форматі RFC 2822, які часто зустрічаються в електронних повідомленнях.--date=short
показує лише дату, але не час, у форматі РРРР-ММ-ДД.--date=raw
показує дату в секундах з епохи (1970-01-01 00:00:00 UTC), після чого йде пробіл, а потім часовий пояс як зміщення відносно UTC (+
або-
з чотирма цифрами; перші дві - години, а другі дві - хвилини). Тобто, ніби позначка часу була відформатована за допомогоюstrftime
("%s
%z"
)). Зверніть увагу, що опція-local
не впливає на значення seconds-since-epoch (яке завжди вимірюється в UTC), але змінює супутнє значення часового поясу.--date=human
показує часовий пояс, якщо часовий пояс не відповідає поточному часовому поясу, і не друкує повну дату, якщо вона збігається (тобто пропускає вивід року для дат, які є "цього року", але також пропускає всю дату, якщо вона в останні кілька днів, і ми можемо просто сказати, який це був день тижня). Для старіших дат година та хвилина також пропускаються.--date=unix
показує дату як позначку часу епохи Unix (секунди з 1970 року). Як і у випадку з--raw
, це завжди в UTC, тому-local
не має жодного ефекту.--date=format:
<format> передає <format> до вашої системноїstrftime
, за винятком%s
,%z
та%Z
, які обробляються внутрішньо. Використовуйте--date=format:%c
, щоб відобразити дату у форматі, що відповідає бажаному формату вашої системної локалізації. Повний список заповнювачів формату дивіться в посібникуstrftime
(3). Під час використання-local
правильний синтаксис —--date=format-local:
<format>.--date=default
– це формат за замовчуванням, який базується на виводі ctime(3). Він показує один рядок із трилітерним днем тижня, трилітерним місяцем, днем місяця, годинами-хвилинами-секундами у форматі "ГГ:ХХ:СС", далі 4-значний рік та інформація про часовий пояс, якщо не використовується місцевий часовий пояс, наприклад,Thu
Jan
1
00:00:00
1970
+0000
. -
-
--header
-
Вивести вміст коміту у форматі RAW; кожен запис розділяється символом NUL.
-
--no-commit-header
-
Приховувати рядок заголовка, що містить "commit" та ідентифікатор об’єкта, що друкується перед зазначеним форматом. Це не впливає на вбудовані формати; впливають лише на користувацькі формати.
-
--commit-header
-
Перезаписує попередній
--no-commit-header
. -
--parents
-
Також вивести батьківські елементи коміту (у форматі "commit parent…"). Також увімкнути перезапис батьківських елементів, див. "Спрощення історії" вище.
-
--children
-
Також вивести дочірні елементи коміта (у формі "commit child…"). Також увімкнути перезапис батьківських елементів, див. "Спрощення історії" вище.
-
--timestamp
-
Вивести необроблену часову позначку коміту.
-
--left-right
-
Позначає, з якої сторони симетричної різниці досяжний коміт. Коміти з лівого боку мають префікс <, а з правого - >. У поєднанні з
--boundary
ці коміти мають префікс-
.Наприклад, якщо у вас така топологія:
y---b---b branch B / \ / / . / / \ o---x---a---a branch A
ви отримаєте такий результат:
$ git rev-list --left-right --boundary --pretty=oneline A...B >bbbbbbb... 3rd on b >bbbbbbb... 2nd on b <aaaaaaa... 3rd on a <aaaaaaa... 2nd on a -yyyyyyy... 1st on b -xxxxxxx... 1st on a
-
--graph
-
Намалюйте текстове графічне представлення історії комітів у лівій частині виводу. Це може призвести до друку додаткових рядків між коммітами, щоб історія графу відображалася правильно. Не можна поєднувати з
--no-walk
.Це дозволяє переписування батьківських елементів, див. розділ «Спрощення історії» вище.
Це означає використання опції
--topo-order
за замовчуванням, але також можна вказати опцію--date-order
. -
--show-linear-break
[=
<barrier>] -
Коли
--graph
не використовується, усі гілки історії згладжуються, що може ускладнити визначення того, що два послідовні коміти не належать до лінійної гілки. У такому випадку ця опція встановлює бар’єр між ними. Якщо вказано <бар’єр>, то замість рядка за замовчуванням буде показано саме цей рядок. -
--count
-
Виведіть число, яке вказує, скільки комітів було б перераховано, та приховуйте весь інший вивід. При використанні разом з
--left-right
, натомість виведіть кількість лівих та правих комітів, розділених табуляцією. При використанні разом з--cherry-mark
, пропустіть еквівалентні коміти з цих підрахунків та виведіть кількість еквівалентних комітів, розділених табуляцією.
ГАРНІ ФОРМАТИ
Якщо коміт є злиттям, і якщо pretty-format не є oneline
, email
або raw
, перед рядком Author:
вставляється додатковий рядок. Цей рядок починається з "Merge:", і хеші батьківських комітів друкуються, розділені пробілами. Зверніть увагу, що перелічені коміти не обов’язково є списком "прямих" батьківських комітів, якщо ви обмежили свій перегляд історії: наприклад, якщо вас цікавлять лише зміни, пов’язані з певним каталогом або файлом.
Існує кілька вбудованих форматів, і ви можете визначити додаткові формати, встановивши параметр конфігурації pretty.<name> або на іншу назву формату, або на рядок format:
, як описано нижче (див. git-config[1]). Ось детальна інформація про вбудовані формати:
-
oneline
<hash> <title-line>
Це розроблено максимально компактно.
-
short
commit <hash> Author: <author>
<title-line>
-
medium
commit <hash> Author: <author> Date: <author-date>
<title-line>
<повідомлення про повний фіксований запис (full-commit)>
-
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> для традиційного введення різниці.<<
Заповнювачі:
-
Заповнювачі, що розгортаються до одного літерала:
-
Заповнювачі, що впливають на форматування наступних заповнювачів:
-
%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
-
необроблене тіло (розгорнутий об’єкт і тіло)
-
%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
, щоб приховувати рядки, що не є трейлерами, у блоці трейлера. Якщо це небажано, її можна вимкнути за допомогоюonly=false
. Наприклад,%
(trailers:key=Reviewed-by
) показує рядки трейлера з ключемReviewed-by
. -
only
[=
<bool>]: виберіть, чи слід включати не-трейлери рядків з трейлерного блоку. -
separator=
<sep>: вкажіть роздільник, що вставляється між рядками-завершеннями. За замовчуванням використовується символ переведення рядка. Рядок <sep> може містити літеральні коди форматування, описані вище. Щоб використовувати кому як роздільник, необхідно використовувати%x2C
, оскільки в іншому випадку він буде проаналізований як наступний параметр. Наприклад,%
(trailers:key=Ticket,separator=%x2C
) показує всі рядки-завершення, ключем яких є "Ticket", розділені комою та пробілом. -
unfold
[=
<bool>]: Змусити його поводитися так, ніби для interpret-trailer було задано опцію--unfold
. Наприклад,%
(trailers:only,unfold=true
) розгортає та показує всі рядки трейлера. -
keyonly
[=
<bool>]: покажіть лише ключову частину трейлера. -
valueonly
[=
<bool>]: покажіть лише ціннісну частину трейлера. -
key_value_separator=
<sep>: вкажіть роздільник, що вставляється між ключем і значенням кожного трейлера. За замовчуванням використовується значення ": ". В іншому випадку він має ту саму семантику, що йseparator=
<sep> вище.
-
-
Note
|
Деякі заповнювачі можуть залежати від інших опцій, наданих механізму проходження версій. Наприклад, опції %g* reflog вставлятимуть порожній рядок, якщо ми не проходимо записи 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 rev-list HEAD
-
Вивести список комітів у цій гілці, але тих, що відсутні у гілці upstream.
git rev-list @{upstream}..HEAD
-
Форматуйте коміти з їхнім автором та повідомленням коміта (див. також посилання на git-log[1]).
git rev-list --format=medium HEAD
-
Форматувати коміти разом з їхніми різницями (див. також porcelain git-log[1], який може зробити це за один процес).
git rev-list HEAD | git diff-tree --stdin --format=medium -p
-
Вивести список комітів у поточній гілці, які торкнулися будь-якого файлу в каталозі
Documentation
.git rev-list HEAD -- Документація/
-
Виведіть список комітів, створених вами за минулий рік, на будь-якій гілці, тегу чи іншому посиланні.
git rev-list --author=you@example.com --since=1.year.ago --all
-
Вивести список об’єктів, досяжних з поточної гілки (тобто всі коміти та блоби й дерева, які вони містять).
git rev-list --objects HEAD
-
Порівняйте розмір диска всіх доступних об’єктів з тими, що доступні з reflogs, та загальний розмір упакованого файлу. Це може показати вам, чи може виконання команди
git
repack
-ad
зменшити розмір репозиторію (шляхом видалення недоступних об’єктів), і чи можуть допомогти reflogs, термін дії яких закінчується.# reachable objects git rev-list --disk-usage --objects --all # plus reflogs git rev-list --disk-usage --objects --all --reflog # total disk size used du -c .git/objects/pack/*.pack .git/objects/??/* # alternative to du: add up "size" and "size-pack" fields git count-objects -v
-
Повідомляти про розмір диска кожної гілки, не враховуючи об’єкти, що використовуються поточною гілкою. Це може виявити викиди, які сприяють роздуттю розміру репозиторію (наприклад, через те, що хтось випадково закомітив великі артефакти збірки).
git for-each-ref --format='%(refname)' | while read branch do size=$(git rev-list --disk-usage --objects HEAD..$branch) echo "$size $branch" done | sort -n
-
Порівняйте розмір гілок на диску в одній групі посилань, виключаючи іншу. Якщо ви змішуєте об’єкти з кількох віддалених серверів в одному репозиторії, це може показати, які віддалені сервери сприяють розміру репозиторію (беручи розмір
origin
за базовий).git rev-list --disk-usage --objects --remotes=$suspect --not --remotes=origin
GIT
Частина набору git[1]