Git

git-rev-parse last updated in 2.52.0

НАЗВА

git-rev-parse - Вибір та визначення параметрів

СИНОПСИС

git rev-parse [<options>] <arg>…

ОПИС

Багато порцелянових команд Git приймають суміш прапорців (тобто параметрів, що починаються з тире -) та параметрів, призначених для базової команди git rev-list, яку вони використовують внутрішньо, а також прапорців і параметрів для інших команд, які вони використовують після git rev-list. Основна мета цієї команди — дозволити викликаючим програмам розрізняти їх. Існує кілька інших режимів роботи, які не мають нічого спільного з вищезгаданими "допомогою розібрати параметри командного рядка".

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

ОПЦІЇ

Режими роботи

Кожен із цих параметрів має з’явитися першим у командному рядку.

--parseopt: Використовуйте git rev-parse у режимі розбору опцій (див. розділ PARSEOPT нижче). Команду в цьому режимі можна використовувати поза репозиторієм або робочим деревом, що контролюється репозиторієм.
--sq-quote: Використовуйте git rev-parse у режимі цитування оболонки (див. розділ SQ-QUOTE нижче). На відміну від опції --sq нижче, цей режим виконує лише цитування. Більше нічого не робиться з введенням команди. Команда в цьому режимі може бути використана поза репозиторієм або робочим деревом, контрольованим репозиторієм.

Варіанти для --parseopt

--keep-dashdash: Має значення лише в режимі --parseopt. Наказує синтаксичному аналізу опцій виводити перший зустрінутий -- замість того, щоб пропускати його.
--stop-at-non-option: Має значення лише в режимі --parseopt. Дозволяє синтаксичному аналізу опцій зупинитися на першому аргументі, який не є опцією. Це можна використовувати для розбору підкоманд, які самі приймають опції.
--stuck-long: Має значення лише в режимі --parseopt. Виведіть параметри у їхньому розгорнутому вигляді, якщо вони доступні, та з їхніми аргументами, що залишилися.

Параметри фільтрації

--revs-only: Не виводити прапорці та параметри, не призначені для команди git rev-list.
--no-revs: Не виводити прапорці та параметри, призначені для команди git rev-list.
--flags: Не виводьте параметри, що не є прапорцями.
--no-flags: Не виводьте параметри прапорців.

Параметри виводу

--default <arg>

Якщо користувач не вказав параметр, використовуйте замість нього <arg>.

--prefix <arg>

Поводитися так, ніби git rev-parse було викликано з підкаталогу <arg> робочого дерева. Будь-які відносні імена файлів розпізнаються так, ніби вони мають префікс <arg>, і будуть виведені у цьому вигляді.

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

prefix=$(git rev-parse --show-prefix)
cd "$(git rev-parse --show-toplevel)"
# rev-parse provides the -- needed for 'set'
eval "set $(git rev-parse --sq --prefix "$prefix" -- "$@")"

--verify

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

Якщо ви хочете переконатися, що вивід дійсно називає об’єкт у вашій базі даних об’єктів та/або може бути використаний як певний тип об’єкта, який вам потрібен, ви можете додати оператор відшаровування ^{type} до параметра. Наприклад, git rev-parse "$VAR^{commit}" гарантує, що $VAR називатиме існуючий об’єкт, який є комітом (тобто коміт або анотований тег, що вказує на коміт). Щоб переконатися, що $VAR називає існуючий об’єкт будь-якого типу, можна використовувати git rev-parse "$VAR^{object}".

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

-q

--quiet

Має значення лише в режимі --verify. Не виводити повідомлення про помилку, якщо перший аргумент не є коректним ім’ям об’єкта; натомість завершити роботу з ненульовим статусом без жодних зусиль. SHA-1 для коректних імен об’єктів виводяться на стандартний вивід у разі успіху.

--sq

Зазвичай вивід виконується в один рядок на кожен прапорець та параметр. Ця опція робить вивід одним рядком, належним чином взятим у лапки для використання оболонкою. Корисно, коли ви очікуєте, що ваш параметр містить пробіли та символи нового рядка (наприклад, під час використання pickaxe -S з git diff-*). На відміну від опції --sq-quote, введені команди все ще інтерпретуються як завжди.

--short[=<довжина>]

Те саме, що й --verify, але скорочує назву об’єкта до унікального префікса з принаймні символами length. Мінімальна довжина — 4, значення за замовчуванням дорівнює ефективному значенню змінної конфігурації core.abbrev (див. git-config[1]).

--not

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

--abbrev-ref[=(strict|loose)]

Неоднозначна коротка назва об’єкта. Для вибору режиму суворого скорочення використовується параметр core.warnAmbiguousRefs.

--symbolic

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

--symbolic-full-name

Це схоже на --symbolic, але воно пропускає вхідні дані, які не є посиланнями (тобто назви гілок або тегів; або, більш чітко, форму "heads/master", що усуває неоднозначність, коли ви хочете назвати гілку "master", коли є тег з невдалою назвою "master"), і показує їх як повні назви посилань (наприклад, "refs/heads/master").

--output-object-format=(sha1|sha256|storage)

Дозволити введення oids з будь-якого формату об’єктів, який підтримує поточний репозиторій.

Вказівка "sha1" за потреби перетворює та повертає sha1 oid.

Вказівка "sha256" за потреби перетворює та повертає oid sha256.

Вказівка "storage" за потреби перетворює значення та повертає oid, закодоване в алгоритмі хешування сховища.

Параметри для об’єктів

--all: Показати всі посилання, знайдені в refs/.
--branches[=<pattern>]
--tags[=<pattern>]
--remotes[=<pattern>]: Показати всі гілки, теги або гілки віддаленого відстеження відповідно (тобто посилання, знайдені в refs/heads, refs/tags або refs/remotes відповідно).

Якщо задано шаблон, відображаються лише посилання, що відповідають заданому глобусу оболонки. Якщо шаблон не містить символу глобулювання (?, * або [), він перетворюється на префіксний збіг шляхом додавання /*.
--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 і скидається після їх обробки.
--disambiguate=<prefix>: Показати кожен об’єкт, ім’я якого починається із заданого префікса. <префікс> має містити щонайменше 4 шістнадцяткові цифри, щоб уникнути помилкового перерахування кожного об’єкта в репозиторії.

Параметри для файлів

--local-env-vars: Перелічіть змінні середовища GIT_*, які є локальними для репозиторію (наприклад, GIT_DIR або GIT_WORK_TREE, але не GIT_EDITOR). Перелічено лише назви змінних, а не їхні значення, навіть якщо вони встановлені.
--path-format=(absolute|relative): Керує поведінкою деяких інших параметрів. Якщо вказано як абсолютний, шляхи, що виводяться цими параметрами, будуть абсолютними та канонічними. Якщо вказано як відносний, шляхи будуть відносними до поточного робочого каталогу, якщо це можливо. Значення за замовчуванням залежить від параметра.

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

Наступні опції змінюються за допомогою параметра --path-format:

--git-dir: Показувати $GIT_DIR, якщо визначено. В іншому випадку показувати шлях до каталогу .git. Показаний шлях, якщо він відносний, є відносним до поточного робочого каталогу.

Якщо $GIT_DIR не визначено, і поточний каталог не виявлено в репозиторії Git або робочому дереві, вивести повідомлення на stderr та завершити роботу з ненульовим статусом.
--git-common-dir: Показувати $GIT_COMMON_DIR, якщо визначено, інакше $GIT_DIR.
--resolve-git-dir <path>: Перевірити, чи <шлях> є дійсним репозиторієм або git-файлом, який вказує на дійсний репозиторій, та вивести розташування репозиторію. Якщо <шлях> є git-файлом, то вивести визначений шлях до справжнього репозиторію.
--git-path <path>: Вирішує проблему з "$GIT_DIR/<шлях>" та враховує інші змінні переміщення шляху, такі як $GIT_OBJECT_DIRECTORY, $GIT_INDEX_FILE…. Наприклад, якщо $GIT_OBJECT_DIRECTORY встановлено на /foo/bar, тоді "git rev-parse --git-path objects/abc" повертає /foo/bar/abc.
--show-toplevel: Показати (за замовчуванням абсолютний) шлях до каталогу верхнього рівня робочого дерева. Якщо робочого дерева немає, повідомити про помилку.
--show-superproject-working-tree: Показати абсолютний шлях до кореня робочого дерева суперпроекту (якщо існує), який використовує поточний репозиторій як свій субмодуль. Нічого не виводить, якщо поточний репозиторій не використовується як субмодуль жодним проєктом.
--shared-index-path: Показати шлях до спільного файлу індексу в режимі розділеного індексу або порожній, якщо не в режимі розділеного індексу.

Наступні опції не залежать від --path-format:

--absolute-git-dir: Подібно до --git-dir, але його вивід завжди є канонізованим абсолютним шляхом.
--is-inside-git-dir: Коли поточний робочий каталог знаходиться нижче каталогу репозиторію, виведіть "true", інакше "false".
--is-inside-work-tree: Коли поточний робочий каталог знаходиться всередині робочого дерева репозиторію, виведіть "true", інакше "false".
--is-bare-repository: Коли репозиторій чистий, вивести "true", інакше "false".
--is-shallow-repository: Коли репозиторій поверхневий, вивести "true", інакше "false".
--show-cdup: Коли команда викликається з підкаталогу, відображає шлях до каталогу верхнього рівня відносно поточного каталогу (зазвичай послідовність "../" або порожній рядок).
--show-prefix: Коли команда викликається з підкаталогу, показати шлях до поточного каталогу відносно каталогу верхнього рівня.
--show-object-format[=(storage|input|output|compat)]: Показує формат об’єкта (алгоритм хешування), який використовується для репозиторію для зберігання в каталозі .git, вхідних даних, виводу або сумісності. Для вхідних даних можна вивести кілька алгоритмів, розділених пробілами. Якщо запитується compat, але алгоритм сумісності не ввімкнено, виводить порожній рядок. Якщо не вказано, значення за замовчуванням — "storage".
--show-ref-format: Показати формат сховища посилань, який використовується для репозиторію.

Інші варіанти

--since=<рядок дати>
--after=<рядок дати>: Розберіть рядок дати та виведіть відповідний параметр --max-age= для git rev-list.
--until=<рядок дати>
--before=<рядок дати>: Розберіть рядок дати та виведіть відповідний параметр --min-age= для git rev-list.
<arg>…: Прапорці та параметри, що підлягають розбору.

ВИЗНАЧЕННЯ РЕВІЗІЙ

Параметр версії <rev> зазвичай, хоча й не обов’язково, позначає об’єкт коміту. Він використовує так званий синтаксис розширеного SHA-1. Нижче наведено різні варіанти написання імен об’єктів. Ті, що вказані в кінці цього списку, позначають дерева та блоби, що містяться в коміті.

Note	У цьому документі показано "сирий" синтаксис, як його бачить git. Оболонка та інші інтерфейси можуть вимагати додаткових лапок для екранування спеціальних символів та уникнення розбиття слів.

<sha1>, напр. dae86e1950b1277e545cee180551750029cfe735, dae86e

Повне імʼя обʼєкта у форматі SHA-1 (16-бітовий шістнадцятковий рядок) або початкова частина рядка, яка є унікальною в межах репозиторію. Наприклад, dae86e1950b1277e545cee180551750029cfe735 і dae86e позначають один і той самий об’єкт коміту, якщо у вашому репозиторії немає іншого об’єкта, ім’я якого починається з dae86e.

<describeOutput>, напр. v1.7.4.2-679-g3bee7fb

Вивід з git describe; тобто найближчий тег, за яким необовʼязково слідує дефіс та кількість комітів, а потім дефіс, g та скорочена назва обʼєкта.

<refname>, напр. master, heads/master, refs/heads/master

Символічне імʼя посилання. Наприклад, master зазвичай означає обʼєкт коміту, на який посилається refs/heads/master. Якщо у вас є як heads/master, так і tags/master, ви можете явно вказати heads/master, щоб пояснити Git, який саме обʼєкт ви маєте на увазі. У разі неоднозначності <refname> розшифровується шляхом вибору першого збігу за такими правилами:

Якщо $GIT_DIR/<refname> існує, саме це ви маєте на увазі (зазвичай це корисно лише для HEAD, FETCH_HEAD, ORIG_HEAD, MERGE_HEAD, REBASE_HEAD, REVERT_HEAD, CHERRY_PICK_HEAD, BISECT_HEAD та AUTO_MERGE);
інакше, refs/<refname>, якщо існує;
інакше, refs/tags/<refname>, якщо існує;
інакше, refs/heads/<refname>, якщо існує;
інакше, refs/remotes/<refname>, якщо існує;
інакше, refs/remotes/<refname>/HEAD, якщо існує.

HEAD

вказує коміт, на якому базуються зміни у робочому дереві.

FETCH_HEAD

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

ORIG_HEAD

створюється командами, які різко змінюють положення HEAD (git am, git merge, git rebase, git reset), щоб зафіксувати положення HEAD до виконання цих операцій, завдяки чому ви зможете легко повернути кінець гілки до стану, що існував до їх виконання.

MERGE_HEAD

записує коміти, які ви зливаєте у свою гілку, коли ви запускаєте git merge.

REBASE_HEAD

під час перебазування, записує коміт, на якому операція наразі зупинена — чи то через конфлікти, чи то через команду edit у інтерактивному перебазуванні.

REVERT_HEAD

записує коміт, який ви скасовуєте під час виконання команди git revert.

CHERRY_PICK_HEAD

записує коміт, який ви вибираєте, коли запускаєте git cherry-pick.

BISECT_HEAD

записує поточний коміт для перевірки під час запуску git bisect --no-checkout.

AUTO_MERGE

записує об’єкт дерева, що відповідає стану, який стратегія злиття «ort» записала у робоче дерево, коли операція злиття призвела до конфліктів.

Зверніть увагу, що будь-який із наведених вище випадків refs/* може походити або з теки $GIT_DIR/refs, або з файлу $GIT_DIR/packed-refs. Хоча кодування назв посилань не вказано, перевага надається UTF-8, оскільки деякі процеси обробки виводу можуть передбачати назви посилань у форматі UTF-8.

@

Сам по собі символ @ є скороченням для HEAD.

[<refname>]@{<date>}, напр. master@{yesterday}, HEAD@{5 minutes ago}

Посилання, за яким іде суфікс @ із зазначенням дати в дужках (наприклад, {yesterday}, {1 month 2 weeks 3 days 1 hour 1 second ago} або {1979-02-26 18:30:00}), вказує на значення посилання в попередній момент часу. Цей суфікс можна використовувати лише безпосередньо після імені посилання, і посилання повинно мати наявний журнал ($GIT_DIR/logs/<ref>). Зверніть увагу, що це дозволяє перевірити стан вашого локального посилання на певний момент часу; наприклад, що було у вашій локальній гілці «master» минулого тижня. Якщо ви хочете переглянути коміти, зроблені протягом певного періоду, дивіться --since та --until.

<refname>@{<n>}, напр. master@{1}

Посилання, за яким стоїть суфікс @ з порядковим номером в дужках (наприклад, {1}, {15}), вказує n-те попереднє значення цього посилання. Наприклад, master@{1} — це безпосереднє попереднє значення master, тоді як master@{5} — це 5-те попереднє значення master. Цей суфікс можна використовувати лише безпосередньо після назви посилання, і посилання повинно мати наявний журнал ($GIT_DIR/logs/<refname>).

@{<n>}, напр. @{1}

Ви можете використовувати конструкцію @ з порожньою частиною ref, щоб отримати запис reflog поточної гілки. Наприклад, якщо ви знаходитесь на гілці blabla, то @{1} означає те саме, що й blabla@{1}.

@{-<n>}, напр. @{-1}

Конструкція @{-<n>} означає, що <n>-та гілка/коміт була активною перед поточною.

[<branchname>]@{upstream}, напр. master@{upstream}, @{u}

Гілку B можна налаштувати для створення поверх гілки X (налаштованої за допомогою branch.<name>.merge) на віддаленому R (налаштованому за допомогою branch.<name>.remote). B@{u} посилається на гілку віддаленого відстеження для гілки X, взятої з віддаленого R, яка зазвичай знаходиться за адресою refs/remotes/R/X.

[<branchname>]@{push}, напр. master@{push}, @{push}

Суфікс @{push} вказує гілку, "куди ми надішлемо зміни", якщо git push було виконано під час переходу на branchname (або поточний HEAD, якщо branchname не вказано). Як і для @{upstream}, ми повідомляємо гілку віддаленого відстеження, яка відповідає цій гілці на віддаленому сервері.

Ось приклад, щоб було зрозуміліше:

$ git config push.default current
$ git config remote.pushdefault myfork
$ git switch -c mybranch origin/master

$ git rev-parse --symbolic-full-name @{upstream}
refs/remotes/origin/master

$ git rev-parse --symbolic-full-name @{push}
refs/remotes/myfork/mybranch

Зверніть увагу, що в прикладі ми налаштували трикутний робочий процес, де ми витягуємо дані з одного місця та надсилаємо їх до іншого. У нетрикутному робочому процесі @{push} те саме, що й @{upstream}, і в цьому немає потреби.

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

<rev>^[<n>], напр. HEAD^, v1.5.1^0

Суфікс ^ до параметра ревізії означає першого батька цього обʼєкта коміту. ^<n> означає <n>-го батька (тобто <rev>^ еквівалентно <rev>^1). Як спеціальне правило, <rev>^0 означає сам коміт і використовується, коли <rev> є назвою обʼєкта тегу, який посилається на обʼєкт коміту.

<rev>~[<n>], напр. HEAD~, master~3

Суфікс ~ у параметрі ревізії означає першого предка цього об’єкта коміту. Суфікс ~<n> у параметрі ревізії означає об’єкт коміту, який є <n>-м поколінням предка вказаного об’єкта коміту, враховуючи лише перших предків. Тобто <rev>~3 еквівалентно <rev>^^^, що еквівалентно <rev>^1^1^1. Дивіться нижче ілюстрацію використання цієї форми.

<rev>^{<type>}, напр. v0.99.8^{commit}

Суфікс ^, за яким іде назва типу об’єкта в дужках, означає рекурсивне розгортання об’єкта в <rev> доти, доки не буде знайдено об’єкт типу <type> або розгортання об’єкта стане неможливим (у цьому випадку — barf) . Наприклад, якщо <rev> є об’єктом типу commit, <rev>^{commit} описує відповідний об’єкт коміту. Аналогічно, якщо <rev> є обʼєктом типу дерева, <rev>^{tree} описує відповідний обʼєкт дерева. <rev>^0 є скороченим записом для <rev>^{commit}.

<rev>^{object} можна використовувати, щоб переконатися, що <rev> вказує на наявних обʼєкт, без необхідності, щоб <rev> був тегом, і без розгортання <rev>; оскільки тег вже є обʼєктом, його не потрібно розгортати жодного разу, щоб дістатися до обʼєкта.

<rev>^{tag} можна використовувати, щоб переконатися, що <rev> ідентифікує наявний обʼєкт тегу.

<rev>^{}, напр. v0.99.8^{}

Суфікс ^, за яким йде порожня пара дужок, означає, що обʼєкт може бути тегом, і тег може бути розгортнутий рекурсивно, доки не буде знайдено обʼєкт, який не є тегом.

<rev>^{/<text>}, напр. HEAD^{/fix nasty bug}

Суфікс ^ до параметра ревізії, за яким йде пара фігурних дужок, що містить текст, що починається зі скісної риски, такий самий, як і синтаксис :/fix nasty bug нижче, за винятком того, що він повертає наймолодший відповідний коміт, який можна досягти з <rev> перед ^.

:/<text>, напр. :/fix nasty bug

Двокрапка, за якою йде скісна риска, а потім текст, позначає коміт, повідомлення якого відповідає вказаному регулярному виразу. Ця назва повертає найновіший коміт, що відповідає критеріям пошуку, до якого можна дістатися з будь-якого посилання, включаючи HEAD. Регулярний вираз може відповідати будь-якій частині повідомлення коміту. Щоб знайти повідомлення, що починаються з певного рядка, можна використати, наприклад, :/^foo. Спеціальна послідовність :/! зарезервована для модифікаторів результату пошуку. :/!-foo виконує негативний пошук, тоді як “:/!!foo” знаходить символ ! у прямому значенні, за яким йде foo. Будь-яка інша послідовність, що починається з :/!, наразі зарезервована. Залежно від вказаного тексту, правила розбиття слів оболонки можуть вимагати додаткового використання лапок.

<rev>:<path>, напр. HEAD:README, master:./README

Суфікс :, за яким іде шлях, позначає об’єкт blob або дерево за вказаним шляхом у об’єкті типу дерево, назва якого вказано в частині перед двокрапкою. Шлях, що починається з ./ або ../, є відносним до поточної робочої теки. Зазначений шлях буде перетворено на відносний до кореневої теки робочого дерева. Це найбільш корисно для звернення до блобу або дерева з коміту або дерева, що має таку саму структуру, як і робоче дерево.

:[<n>:]<path>, напр. :0:README, :README

Двокрапка, за якою може йти номер stage (від 0 до 3) та ще одна двокрапка, а потім шлях, позначає об’єкт blob в індексі за вказаним шляхом. Відсутність номера stage (та двокрапки, що йде за ним) позначає запис stage 0. Під час злиття stage 1 є спільним предком, stage 2 — версією цільової гілки (зазвичай поточної гілки), а stage 3 — версією з гілки, що зливається.

Ось ілюстрація Джона Лоелігера. Обидва вузли комітів B та C є батьківськими для вузла коміта A. Батьківські коміти впорядковані зліва направо.

G   H   I   J
 \ /     \ /
  D   E   F
   \  |  / \
    \ | /   |
     \|/    |
      B     C
       \   /
        \ /
         A

A =      = A^0
B = A^   = A^1     = A~1
C =      = A^2
D = A^^  = A^1^1   = A~2
E = B^2  = A^^2
F = B^3  = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2  = B^^2    = A^^^2  = A~2^2
I = F^   = B^3^    = A^^3^
J = F^2  = B^3^2   = A^^3^2

ВИЗНАЧЕННЯ ДІАПАЗОНІВ

Команди для перегляду історії, такі як git log, працюють з набором комітів, а не з окремим комітом.

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

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

Доступний набір коміту — це сам коміт та коміти в його ланцюжку попередників.

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

Винятки комітів

Нотація з кареткою ^<rev>: Щоб виключити коміти, до яких можна дістатися з певного коміту, використовується префікс ^. Наприклад, ^r1 r2 означає коміти, до яких можна дістатися з r2, але виключає ті, до яких можна дістатися з r1 (тобто r1 та його попередників).

Позначення діапазонів крапками

Нотація діапазону .. (двокрапка): Операція з набором ^r1 r2 зустрічається настільки часто, що для неї існує скорочена форма. Якщо у вас є два коміти r1 і r2 (позначені відповідно до синтаксису, описаного вище у розділі ВИЗНАЧЕННЯ РЕВІЗІЙ, ви можете запитати коміти, доступні з r2, виключаючи ті, що доступні з r1, за допомогою ^r1 r2, і це можна записати як r1..r2.
Симетрична різниця ... (три крапки): Подібне позначення r1...r2 називається симетричною різницею r1 та r2 та визначається як r1 r2 --not $(git merge-base --all r1 r2). Це набір комітів, які доступні з одного з r1 (ліва сторона) або r2 (права сторона), але не з обох.

У цих двох скорочених записах можна пропустити один кінець і дозволити йому використовувати HEAD. Наприклад, origin.. — це скорочення від origin..HEAD і запитує: "Що я зробив після того, як зроби відгалуження від гілки origin?". Аналогічно, ..origin — це скорочення від HEAD..origin і запитує: "Що зробила гілка origin після того, як я зробив відгалуження від неї?". Зверніть увагу, що .. означатиме HEAD..HEAD, який є порожнім діапазоном, досяжним і недосяжним з HEAD.

Команди, спеціально розроблені для використання двох різних діапазонів (наприклад, "git range-diff R1 R2" для порівняння двох діапазонів), існують, але вони є винятками. Якщо не зазначено інше, усі команди "git", які працюють з набором комітів, працюють з одним діапазоном версій. Іншими словами, запис двох "двокрапкових позначень діапазону" поруч один з одним, наприклад.

$ git log A..B C..D

не визначає два діапазони версій для більшості команд. Натомість він вкаже єдину зв’язану сукупність комітів, тобто тих, до яких можна дістатися з B або D, але не з A чи C. У такій лінійній історії:

---A---B---o---o---C---D

Оскільки A та B досяжні з C, діапазон версій, визначений цими двома крапковими діапазонами, є одним комітом D.

Інші скорочені позначення батьківських елементів через <rev>^

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

Нотація r1^@ означає всіх батьківських елементів r1.

Запис r1^! включає коміт r1, але виключає всі його батьківські коміти. Сам по собі цей запис означає єдиний коміт r1.

Запис <rev>^-[<n>] включає <rev>, але виключає <n>-й батьківський елемент (тобто скорочення для <rev>^<n>..<rev>), де <n> = 1, якщо не вказано. Зазвичай це корисно для комітів злиття, де ви можете просто передати <commit>^-, щоб отримати всі коміти у гілці, яка була обʼєднана в коміті злиття <commit> (включаючи сам <commit>).

Хоча <rev>^<n> стосувалося визначення одного батьківського елемента коміта, ці три позначення також враховують його батьківські елементи. Наприклад, ви можете сказати HEAD^2^@, проте ви не можете сказати HEAD^@^2.

Короткий огляд діапазону ревізії

<rev>: Включити коміти, доступні з <rev> (тобто <rev> та його предків).
^<rev>: Виключити коміти, досяжні з <rev> (тобто <rev> та його предків).
<rev1>..<rev2>: Включити коміти, доступні з <rev2>, але виключити ті, доступні з <rev1>. Якщо <rev1> або <rev2> пропущено, зазвичай використовується значення HEAD.
<rev1>...<rev2>: Включити коміти, доступні з <rev1> або <rev2>, але виключити ті, доступні з обох. Якщо <rev1> або <rev2> пропущено, зазвичай використовується значення HEAD.
<rev>^@, напр. HEAD^@: Суфікс ^, після якого стоїть знак at, те саме, що й перелік усіх батьківських обʼєктів <rev> (тобто, включено все, що доступно з батьківських обʼєктів, але не сам коміт).
<rev>^!, напр. HEAD^!: Суфікс ^, за яким стоїть знак оклику, те саме, що додати коміт <rev> та всі його батьківські елементи з префіксом ^, щоб виключити їх (та їхніх предків).
<rev>^-<n>, напр. HEAD^-, HEAD^-2: Еквівалентно <rev>^<n>..<rev>, де <n> = 1, якщо не вказано.

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

   Аргументи  Розширені аргументи  Вибрані коміти
   D                            G H D
   D F                          G H I J D F
   ^G D                         H D
   ^D B                         E I J F B
   ^D B C                       E I J F B C
   C                            I J F C
   B..C   = ^B C                C
   B...C  = B ^F C              G H D E B C
   B^-    = B^..B
	  = ^B^1 B              E I J F B
   C^@    = C^1
	  = F                   I J F
   B^@    = B^1 B^2 B^3
	  = D E F               D G H E F I J
   C^!    = C ^C^@
	  = C ^C^1
	  = C ^F                C
   B^!    = B ^B^@
	  = B ^B^1 ^B^2 ^B^3
	  = B ^D ^E ^F          B
   F^! D  = F ^I ^J D           G H D F

ПАРСЕОПТ

У режимі --parseopt, git rev-parse допомагає з опціями, щоб надати скриптам оболонки ті ж можливості, що й вбудовані функції C. Він працює як нормалізатор опцій (наприклад, розділяє агреговані значення окремих перемикачів), трохи подібно до getopt(1).

Він приймає на стандартний вхід специфікацію опцій для розбору та розуміння, а на стандартний вивід виводить рядок, придатний для sh(1) eval, щоб замінити аргументи нормалізованими. У разі помилки він виводить використання у стандартному потоці помилок та завершує роботу з кодом 129.

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

Формат введення

Формат вхідних даних git rev-parse --parseopt повністю текстовий. Він складається з двох частин, розділених рядком, який містить лише --. Рядки перед роздільником (їх має бути один або більше) використовуються для використання. Рядки після роздільника описують опції.

Кожен рядок опцій має такий формат:

<opt-spec><flags>*<arg-hint>? SP+ help LF

<opt-spec>

його формат такий: спочатку короткий символ опції, потім довга назва опції, розділені комою. Обидві частини не є обов’язковими, хоча принаймні одна є необхідною. Не може містити жодного з символів <flags>. h,help, dry-run та f є прикладами правильного <opt-spec>.

<flags>

<flags> є *, =, ? або !.

Використовуйте =, якщо опція приймає аргумент.
Використовуйте ?, щоб означити, що опція приймає необов’язковий аргумент. Ймовірно, вам варто використовувати режим --stuck-long, щоб мати змогу однозначно розібрати необов’язковий аргумент.
Використовуйте *, щоб означити, що цей параметр не слід вказувати у використанні, згенерованому для аргументу -h. Він відображається для --help-all, як задокументовано в gitcli[7].
Використовуйте символ !, щоб не зробити відповідний заперечений довгий параметр доступним.

<arg-hint>

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

Решта рядка, після видалення пробілів, використовується як довідка, пов’язана з опцією.

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

Приклад

OPTS_SPEC="\
some-command [<options>] <args>...

some-command does foo and bar!
--
г, допоможіть! покажіть допомогу

foo якийсь крутий варіант --foo bar= якийсь крутий варіант --bar з аргументом baz=arg ще один крутий варіант --baz з іменованим аргументом qux?path qux може приймати шлях як аргумент, але має сам по собі значення

  An option group Header
C?        option C with an optional argument"

eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"

Текст використання

Коли "$@" має значення -h або --help у наведеному вище прикладі, буде показано наступний текст використання:

usage: some-command [<options>] <args>...

    some-command виконує foo та bar!

    -h, --help            show the help
    --[no-]foo            some nifty option --foo
    --[no-]bar ...        some cool option --bar with an argument
    --[no-]baz <arg>      another cool option --baz with a named argument
    --[no-]qux[=<path>]   qux may take a path argument but has meaning by itself

An option group Header
    -C[...]               option C with an optional argument

SQ-ЦИТАТА

У режимі --sq-quote, git rev-parse виводить на стандартний вивід один рядок, придатний для sh(1) eval. Цей рядок створюється шляхом нормалізації аргументів після --sq-quote. Нічого, крім взяття аргументів у лапки, не робиться.

Якщо ви хочете, щоб введені команди все ще інтерпретувалися як завжди командою git rev-parse перед тим, як вивід буде взято в лапки оболонки, дивіться опцію --sq.

Приклад

$ cat >your-git-script.sh <<\EOF
#!/bin/sh
args=$(git rev-parse --sq-quote "$@")   # quote user-supplied arguments
command="git frotz -n24 $args"          # and use it inside a handcrafted
					# command line
eval "$command"
EOF

$ sh your-git-script.sh "a b'c"

ПРИКЛАДИ

Вивести назву об’єкта поточного коміту:
```
$ git rev-parse --verify HEAD
```
Вивести назву об’єкта коміту з ревізії у змінній оболонки $REV:
```
$ git rev-parse --verify --end-of-options $REV^{commit}
```
Це призведе до помилки, якщо $REV порожній або не є коректною редакцією.
Подібно до вищезазначеного:
```
$ git rev-parse --default master --verify --end-of-options $REV
```
але якщо $REV порожній, буде виведено ім’я об’єкта коміту з master.

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

НАЗВА

СИНОПСИС

ОПИС

ОПЦІЇ

Режими роботи

Варіанти для --parseopt

Параметри фільтрації

Параметри виводу

Параметри для об’єктів

Параметри для файлів

Інші варіанти

ВИЗНАЧЕННЯ РЕВІЗІЙ

ВИЗНАЧЕННЯ ДІАПАЗОНІВ

Винятки комітів

Позначення діапазонів крапками

Інші скорочені позначення батьківських елементів через <rev>^

Короткий огляд діапазону ревізії

ПАРСЕОПТ

Формат введення

Приклад

Текст використання

SQ-ЦИТАТА

Приклад

ПРИКЛАДИ

GIT