Git

git-rev-parse last updated in 2.45.3

НАЗВА

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)]: Показати формат об’єкта (алгоритм хешування), що використовується для репозиторію для зберігання всередині каталогу .git, вхідних або вихідних даних. Для вхідних даних можна вивести кілька алгоритмів, розділених пробілами. Якщо не вказано, значення за замовчуванням — "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>, e.g. dae86e1950b1277e545cee180551750029cfe735, dae86e

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

<describeOutput>, e.g. v1.7.4.2-679-g3bee7fb

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

<refname>, e.g. 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>}, e.g. master@{yesterday}, HEAD@{5 minutes ago}

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

<refname>@{<n>}, e.g. master@{1}

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

@{<n>}, e.g. @{1}

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

@{-<n>}, e.g. @{-1}

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

[<branchname>]@{upstream}, e.g. master@{upstream}, @{u}

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

[<branchname>]@{push}, e.g. 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>], e.g. HEAD^, v1.5.1^0

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

<rev>~[<n>], e.g. HEAD~, master~3

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

<rev>^{<type>}, e.g. v0.99.8^{commit}

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

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

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

<rev>^{}, e.g. v0.99.8^{}

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

<rev>^{/<text>}, e.g. HEAD^{/fix nasty bug}

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

:/<text>, e.g. ':/виправити неприємну помилку

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

<rev>:<path>, e.g. HEAD:README, master:./README

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

:[<n>:]<path>, e.g. :0:README, :README

Двокрапка, за якою необов’язково слідує номер етапу (від 0 до 3) та двокрапка, а потім шлях, іменує блоб-об’єкт в індексі за заданим шляхом. Відсутній номер етапу (і двокрапка, що йде після нього) іменує запис етапу 0. Під час злиття етап 1 є спільним предком, етап 2 — версією цільової гілки (зазвичай поточної гілки), а етап 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> (caret) Notation: Щоб виключити коміти, досяжні з коміту, використовується префіксна нотація ^. Наприклад, ^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>^@, e.g. HEAD^@: Суфікс ^, після якого стоїть знак at, те саме, що й перелік усіх батьківських об’єктів <rev> (тобто, включено все, що доступно з батьківських об’єктів, але не сам коміт).
<rev>^!, e.g. HEAD^!: Суфікс ^, за яким стоїть знак оклику, те саме, що додати комміт <rev> та всі його батьківські елементи з префіксом ^, щоб виключити їх (та їхніх предків).
<rev>^-<n>, e.g. 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