git-receive-pack - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

git-receive-pack - отримувати те, що поміщено в репозиторій

СИНТАКСИС

git-receive-pack

ОПИС

Викликано мерзотник відправити-пакет і оновлює репозиторій інформацією, що надходить із
віддалений кінець.

Ця команда зазвичай не викликається безпосередньо кінцевим користувачем. Інтерфейс користувача для протоколу
на мерзотник відправити-пакет стороні, і пара програм призначена для використання для надсилання оновлень до
віддалений репозиторій. Про операції витягування див git-fetch-pack(1).

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

Є й інші реальні приклади використання гачків оновлення та пост-оновлення
Документація/довідник інструкцій.

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

ВАРІАНТИ

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

ПОпередньо ОТРИМАТИ ДАК

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

sha1-старий SP sha1-новий SP посилання LF

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

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

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

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

GIT_PUSH_CERT_STATUS
Статус перевірки GPG сертифіката push, використовуючи ту саму мнемоніку, що й
використовується в %G? формат сімейства команд журналу git (див git-log(1)).

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

GIT_PUSH_CERT_NONCE_STATUS

НЕЗАХІДНИЙ
"git push --signed" надіслав одноразовий запис, коли ми не просили його надіслати його.

ВІДСУТНІЙ
"git push --signed" не надіслав жодного заголовка nonce.

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

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

СЛОП
"git push --signed" надіслав nonce, відмінний від того, що ми просили надіслати зараз, але
на попередній сесії. Перегляньте змінну середовища GIT_PUSH_CERT_NONCE_SLOP.

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

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

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

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

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

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

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

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

Успішне виконання (нульовий статус виходу) цього хука не гарантує виконання запиту
насправді оновлюватися, це лише передумова. Тому надсилати не варто
сповіщення (наприклад, електронна пошта) з цього хука. Подумайте про використання гачка після отримання.

ПІСЛЯ ОТРИМАННЯ ДАК

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

sha1-старий SP sha1-новий SP посилання LF

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

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

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

#!/ Бен / ш
# надіслати поштою інформацію про оновлення.
при читанні oval nval ref
do
if expr "$oval" : '0*$' >/dev/null
потім
echo "Створено нове посилання з такими комітами:"
git rev-list --pretty "$nval"
ще
echo "Нові коміти:"
git rev-list --pretty "$nval" "^$oval"
fi |
mail -s "Зміни до ref $ref" commit-list@mydomain
зроблений
# підписаний push сертифікат, якщо є
якщо тест -n "${GIT_PUSH_CERT-}" && тест ${GIT_PUSH_CERT_STATUS} = G
потім
(
Очікуваний одноразовий відлуння становить ${GIT_PUSH_NONCE}
git cat-file blob ${GIT_PUSH_CERT}
) | mail -s "push сертифікат від $GIT_PUSH_CERT_SIGNER" push-log@mydomain
fi
вихід 0

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

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

ПІСЛЯ ОНОВЛЕННЯ ДАК

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

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

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

#!/ Бен / ш
exec git інформація про сервер оновлення

Використовуйте git-receive-pack онлайн за допомогою служб onworks.net