українська мова ▾ 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-посилання (heads/tags) на віддаленому сервері (а точніше, команда git-receive-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. Використання цієї опції без надійного зовнішнього механізму, що забезпечує повну зв’язність доступних обʼєктів, створює ризик пошкодження репозиторію і не повинно використовуватися в загальному випадку.

ГАЧОК PRE-RECEIVE

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

sha1-old SP sha1-new SP refname LF

Значення refname є відносним до $GIT_DIR; наприклад, для вершини master це «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 також не будуть викликані. Це може бути корисним для швидкого виходу, якщо оновлення не підтримується.

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

ГАЧОК UPDATE

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

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

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

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

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

ГАЧОК POST-RECEIVE

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

sha1-old SP sha1-new SP refname LF

Значення refname залежить від $GIT_DIR; наприклад, для вершини master це "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.

ГАЧОК POST-UPDATE

Після всіх інших обробок, якщо хоча б одне посилання було оновлено, і якщо файл $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]