Какая разница между post-receive и post-update?

Я хочу обновить голый репо и заставить его сделать что-то после того, как что-то было нажато на него с помощью крючка. Какой из них я должен использовать? В книге git -scm говорится, что они оба запускаются после обновления всех ссылок, поэтому я не знаю, в чем разница.

Ответы

Ответ 1

В документации :

после приема:

Это заменяет крюк <post-update> тем, что он добавляет как старые, так и новые значения всех ссылок в дополнение к их именам.

после обновления:

Квест "post-update" может рассказать, какие головки были нажаты, но он не знает, каковы их исходные и обновленные значения, поэтому это плохое место для ведения журнала old..new. Крючок <post-receive> получает как исходные, так и обновленные значения ref. Вместо этого вы можете рассмотреть его, если они вам понадобятся.

Ответ 2

A недавний коммит для Git 2.2+ (ноябрь 2014), Юнио С Хамано (gitster) упоминать:

Перехватчики pre-receive и post-receive были разработаны как улучшенные по сравнению с старыми стилями update и post-update, которые принимают информацию об обновлении в своей командной строке и ограничены длиной в командной строке предел.

Эта же информация подается от стандартного ввода до крючков до/после приема, чтобы снять это ограничение.

Для этих новых крючков стиля было обязательным полное использование информации об обновлении из стандартного потока ввода. В противном случае они рискуют убить процесс получения пакета с помощью SIGPIPE.

Теперь он добавляет:

Если крючок не хочет просматривать всю информацию, легко отправить его стандартный ввод на /dev/null (возможно, использование ниши для крючка может потребовать знать только тот факт, что был сделан push, без чтобы узнать, какие объекты были добавлены для обновления, которые ссылаются), и это уже сделано с помощью существующих крючков, которые написаны тщательно.

Однако, поскольку нет хорошего способа последовательно перехватывать крючки, которые не потребляют вход полностью (небольшое нажатие может привести к короткой записи обновления, которая может вписываться в буфер канала, к которой может работать процесс receive-pack для записи до того, как у крючка будет возможность выйти без чтения чего-либо, что не приведет к смерти от SIGPIPE receive-pack), это может привести к тяжелой диагностике "один раз в синей луне" phantom сбой.

Поднимите этот "крючки должны полностью использовать свой вход".