git-receive-pack - Интернет в облаке

ПРОГРАММА:

ИМЯ

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

СИНТАКСИС

git-получить-пакет

ОПИСАНИЕ

Вызвано мерзавец отправить пакет и обновляет репозиторий информацией, полученной из
удаленный конец.

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

Команда позволяет создавать и перематывать ссылки sha1 (заголовки / теги) на
удаленный конец (строго говоря, это локальный конец git-получить-пакет работает, но пользователю
кто сидит в конце send-pack, он обновляет пульт. Смущенный?)

Есть и другие реальные примеры использования хуков обновления и пост-обновления, которые можно найти в
Документация / справочник.

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

ДОПОЛНИТЕЛЬНЫЕ УСЛУГИ, НЕ ВКЛЮЧЕННЫЕ В ПАКЕТ

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

ПРЕДПРИЕМ ЗАКОРЮЧКИ

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

sha1-старый SP sha1-новый имя SP LF

Значение refname относится к $ GIT_DIR; например, для главной головы это
"ссылки / головы / мастер". Два значения sha1 перед каждым именем ссылки являются именами объектов для
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-журнал(1 г.)).

GIT_PUSH_CERT_NONCE
Строка nonce, которую процесс попросил подписывающую сторону включить в push-сертификат. Если
это не соответствует значению, записанному в заголовке "nonce" в push-сертификате,
это может указывать на то, что сертификат действительный, который воспроизводится из
отдельный сеанс "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" отправил одноразовый номер, отличный от того, что мы просили отправить сейчас, но
на предыдущем сеансе. См. Переменную среды GIT_PUSH_CERT_NONCE_SLOP.

GIT_PUSH_CERT_NONCE_SLOP
"git push --signed" отправил одноразовый номер, отличный от того, что мы просили отправить сейчас, но в
другой сеанс, время начала которого на столько секунд отличается от
текущий сеанс. Имеет смысл только тогда, когда GIT_PUSH_CERT_NONCE_STATUS говорит SLOP. Также читайте
о переменной receive.certNonceSlop в git-конфигурация(1).

Этот хук вызывается перед обновлением любого ссылочного имени и перед выполнением любых проверок перемотки вперед.
выполнено.

Если обработчик предварительного приема завершается с ненулевым статусом выхода, обновления выполняться не будут,
и хуки обновления, пост-получения и пост-обновления также не будут вызываться. Это может быть
полезно для быстрого выхода из ситуации, если обновление не будет поддерживаться.

ОБНОВЛЕНИЕ ПО ЗАКОРЮЧКИ

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

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

Параметр refname относится к $ GIT_DIR; например, для главной головы это
"ссылки / головы / мастер". Два аргумента sha1 - это имена объектов для ссылки перед
и после обновления. Обратите внимание, что ловушка вызывается до обновления имени ссылки, поэтому
либо sha1-old равен 0 {40} (то есть такой ссылки еще нет), либо он должен соответствовать тому, что
записано в refname.

Хук должен выйти с ненулевым статусом, если он хочет запретить обновление именованной ссылки.
В противном случае он должен выйти с нулем.

Успешное выполнение (нулевой статус выхода) этого хука не гарантирует, что ссылка будет
собственно обновление, это только обязательное условие. Поэтому отправлять
уведомления (например, электронная почта) от этого хука. Вместо этого рассмотрите возможность использования обработчика post-receive.

ПОСЛЕ ПОЛУЧЕНИЯ ЗАКОРЮЧКИ

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

sha1-старый SP sha1-новый имя SP LF

Значение refname относится к $ GIT_DIR; например, для главной головы это
"ссылки / головы / мастер". Два значения sha1 перед каждым именем ссылки являются именами объектов для
refname до и после обновления. Созданные ссылки будут иметь значение sha1-old, равное
0 {40}, в то время как ссылки, которые были удалены, будут иметь sha1-new, равное 0 {40}, в противном случае sha1-old
и sha1-new должны быть допустимыми объектами в репозитории.

Переменные среды GIT_PUSH_CERT * могут быть проверены, как и в обработчике pre-receive,
после принятия подписанного push-уведомления.

Используя эту ловушку, легко создавать электронные письма с описанием обновлений в репозитории.
Этот пример сценария отправляет одно почтовое сообщение для каждой ссылки, в которой перечислены коммиты, отправленные в
репозиторий, и регистрирует push-сертификаты подписанных push-уведомлений с хорошими подписями в
сервис регистратора:

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

Код выхода из этого вызова ловушки игнорируется, однако ненулевой код выхода будет
генерировать сообщение об ошибке.

Обратите внимание, что для refname может не быть sha1-new при запуске этой ловушки. Это может
легко возникает, если другой пользователь изменяет ссылку после того, как она была обновлена git-получить-пакет,
но до того, как зацепить удалось это оценить. Рекомендуется использовать крючки на sha1-new.
а не текущее значение refname.

ПОСЛЕ ОБНОВЛЕНИЯ ЗАКОРЮЧКИ

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

Код выхода из этого вызова ловушки игнорируется; единственное, что осталось для
git-получить-пакет сделать в этот момент - все равно выйти из себя.

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

#!/ Бен / ш
выполнить git update-server-info

Используйте git-receive-pack онлайн с помощью сервисов onworks.net