українська мова ▾ Topics ▾ Latest version ▾ git-receive-pack last updated in 2.50.0

НАЗВА

git-receive-pack - Отримання того, що надсилається до репозиторію

СИНОПСИС

git receive-pack <git-dir>

ОПИС

Викликається командою git send-pack та оновлює репозиторій інформацією, що надійшла з віддаленого боку.

Ця команда зазвичай не викликається безпосередньо кінцевим користувачем. Інтерфейс користувача для протоколу знаходиться на стороні «git send-pack», а пара програм призначена для використання для надсилання оновлень до віддаленого репозиторію. Щодо операцій pull див. git-fetch-pack[1].

Команда дозволяє створювати та швидко пересилати посилання sha1 (заголовки/теги) на віддаленому кінці (строго кажучи, це локальний кінець, де виконується git-receive-pack, але для користувача, який сидить на стороні send-pack, це оновлення віддаленого. Збентежені?)

Інші реальні приклади використання перехоплювачів update та post-update можна знайти в каталозі Documentation/howto.

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

Для налаштування поведінки receive.* доступний ряд інших параметрів конфігурації, див. git-config[1].

ОПЦІЇ

<git-dir>

Репозиторій для синхронізації.

--http-backend-info-refs

Використовується git-http-backend[1] для обробки запитів $GIT_URL/info/refs?service=git-receive-pack. Див. --http-backend-info-refs у git-upload-pack[1].

--skip-connectivity-check

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

ПОПЕРЕДНЬОГО ПРИЙОМУ ГАЧОК

Перед оновленням будь-якого посилання, якщо файл $GIT_DIR/hooks/pre-receive існує та є виконуваним, він буде викликаний один раз без параметрів. Стандартний вхідний рядок для кожного посилання, яке потрібно оновити, буде один:

sha1-old SP sha1-new SP refname LF

Значення refname залежить від $GIT_DIR; наприклад, для головного заголовка це "refs/heads/master". Два значення sha1 перед кожним refname – це імена об’єктів для refname до та після оновлення. Посилання, що будуть створені, матимуть sha1-old, що дорівнює 0{40}, тоді як посилання, що будуть видалені, матимуть sha1-new, що дорівнює 0{40}, інакше sha1-old та sha1-new повинні бути дійсними об’єктами в репозиторії.

Під час прийняття підписаного push-повідомлення (див. git-push[1]), підписаний push-сертифікат зберігається в blob-об’єкті, а змінна середовища GIT_PUSH_CERT може бути використана для отримання назви його об’єкта. Див. опис хука post-receive для прикладу. Крім того, сертифікат перевіряється за допомогою GPG, а результат експортується з такими змінними середовища:

GIT_PUSH_CERT_SIGNER

Ім’я та адреса електронної пошти власника ключа, який підписав push-сертифікат.

GIT_PUSH_CERT_KEY

Ідентифікатор ключа GPG, який підписав push-сертифікат.

GIT_PUSH_CERT_STATUS

Стан GPG-верифікації push-сертифіката, використовуючи ту саму мнемоніку, що й у форматі %G? сімейства команд git log (див. git-log[1]).

GIT_PUSH_CERT_NONCE

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

GIT_PUSH_CERT_NONCE_STATUS
UNSOLICITED

"git push --signed" надіслав одноразовий код, хоча ми не просили його про це.

MISSING

"git push --signed" не надіслав жодного заголовка nonce.

BAD

"git push --signed" надіслав фальшивий одноразовий код.

OK

"git push --signed" надіслав одноразовий номер, який ми просили надіслати.

SLOP

"git push --signed" надіслав одноразове значення, відмінне від того, яке ми просили надіслати зараз, але в попередньому сеансі. Див. змінну середовища GIT_PUSH_CERT_NONCE_SLOP.

GIT_PUSH_CERT_NONCE_SLOP

"git push --signed" надіслав одноразове значення, відмінне від того, яке ми просили надіслати зараз, але в іншому сеансі, час початку якого відрізняється на стільки ж секунд від поточного сеансу. Має сенс лише тоді, коли GIT_PUSH_CERT_NONCE_STATUS показує SLOP. Також прочитайте про змінну receive.certNonceSlop у git-config[1].

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

Якщо перехоплювач pre-receive завершується з ненульовим статусом завершення, оновлення не будуть виконані, а перехоплювачі update, post-receive та post-update також не будуть викликані. Це може бути корисним для швидкого виходу, якщо оновлення не підтримується.

Дивіться примітки щодо карантинного середовища нижче.

ОНОВЛЕННЯ ХАКА

Перед оновленням кожного посилання, якщо файл $GIT_DIR/hooks/update існує та є виконуваним, він викликається один раз для кожного посилання з трьома параметрами:

$GIT_DIR/hooks/update refname sha1-old sha1-new

Параметр refname залежить від $GIT_DIR; наприклад, для головного заголовка це "refs/heads/master". Два аргументи sha1 – це імена об’єктів для refname до та після оновлення. Зверніть увагу, що гачок викликається перед оновленням refname, тому або sha1-old дорівнює 0{40} (тобто такого посилання ще немає), або воно має відповідати тому, що записано в refname.

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

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

ГАК ПІСЛЯ ПРИЙОМУ

Після оновлення всіх посилань (або спроби оновлення), якщо оновлення будь-якого посилання було успішним, і якщо файл $GIT_DIR/hooks/post-receive існує та є виконуваним, він буде викликаний один раз без параметрів. Стандартний вхідний рядок для кожного успішно оновленого посилання буде:

sha1-old SP sha1-new SP refname LF

Значення refname залежить від $GIT_DIR; наприклад, для головного заголовка це "refs/heads/master". Два значення sha1 перед кожним refname – це імена об’єктів для refname до та після оновлення. Створені посилання матимуть sha1-old, що дорівнює 0{40}, тоді як видалені посилання матимуть sha1-new, що дорівнює 0{40}, інакше sha1-old та sha1-new мають бути дійсними об’єктами в репозиторії.

Змінні середовища GIT_PUSH_CERT* можна перевірити, як і в гачку pre-receive, після прийняття підписаного push-повідомлення.

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

#!/bin/sh
# mail out commit update information.
while read oval nval ref
do
	if expr "$oval" : '0*$' >/dev/null
	then
		echo "Created a new ref, with the following commits:"
		git rev-list --pretty "$nval"
	else
		echo "New commits:"
		git rev-list --pretty "$nval" "^$oval"
	fi |
	mail -s "Changes to ref $ref" commit-list@mydomain
done
# log signed push certificate, if any
if test -n "${GIT_PUSH_CERT-}" && test ${GIT_PUSH_CERT_STATUS} = G
then
	(
		echo expected nonce is ${GIT_PUSH_NONCE}
		git cat-file blob ${GIT_PUSH_CERT}
	) | mail -s "push certificate from $GIT_PUSH_CERT_SIGNER" push-log@mydomain
fi
exit 0

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

Зверніть увагу, що можливо, що refname не матиме sha1-new під час виконання цього гачка. Це може легко статися, якщо інший користувач змінить посилання після його оновлення за допомогою git-receive-pack, але до того, як гачок зміг його обчислити. Рекомендується, щоб гачки покладалися на sha1-new, а не на поточне значення refname.

ПІСЛЯОНОВЛЕННЯ ХУК

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

Код виходу з цього виклику хука ігнорується; єдине, що залишається зробити git-receive-pack у цей момент, це все одно вийти з себе.

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

#!/bin/sh
exec git update-server-info

КАРАНТИННЕ СЕРЕДОВИЩЕ

Коли receive-pack приймає об’єкти, вони поміщаються в тимчасовий каталог "карантин" у каталозі $GIT_DIR/objects та переносяться в основне сховище об’єктів лише після завершення обробки перехоплення pre-receive. Якщо передача не вдається раніше, тимчасовий каталог повністю видаляється.

Це має кілька видимих для користувача ефектів та застережень:

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

  2. Будь-які об’єкти, створені хуком pre-receive, будуть створені в каталозі карантину (і перенесені лише за умови успішного завершення).

  3. Гак pre-receive НЕ ПОВИНЕН оновлювати жодні посилання, щоб вони вказували на об’єкти в карантині. Інші програми, які мають доступ до репозиторію, не зможуть бачити ці об’єкти (і якщо гак pre-receive не спрацює, ці посилання будуть пошкоджені). З міркувань безпеки будь-які оновлення посилань з pre-receive автоматично відхиляються.

ДИВ. ТАКОЖ

git-send-pack[1], gitnamespaces[7]

GIT

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