Уведомление на почту обо всех изменениях в репозитории (git commit, git pull)

типа чтобы контролировать что там делают какие то засранцы? может просто проще засранцев оттуда выпилить?)

а вот как сделать подписку на изменения, приходящие с git pull?

Если я правильно понял, и все коммиты отправляются в главный репозиторий, то тамошний post-receive должен перехватывать всё, что потом может быть стянуто через git pull. Если вы боитесь, что кто-то поправил что-то на боевом сервере, то надо бить по рукам за такое. Если кто-то закоммитил с боевого сервера на главный, то в принципе какая разница, откуда пришёл коммит, главное чтоб в нужную ветку и с настроенным профайлом (просто чтоб было ясно, что коммит совершил не root@grendizer.com, а Петя Иванов ivanov@petya.ru)

можно ли как-то отправлять не только уведомление, но и дифф?

git diff?

типа чтобы контролировать что там делают какие то засранцы?

Ага.

может просто проще засранцев оттуда выпилить?)

«Хочешь чтоб было сделано хорошо - сделай сам»? :) Не, там на часть рутинных изменений «засранцам» составлена инструкция и они работают строго по ней. Автоматизировать, увы, пока не получается, а самому этой рутиной заниматься лень, поэтому просто контролирую.

Если я правильно понял, и все коммиты отправляются в главный репозиторий, то тамошний post-receive должен перехватывать всё, что потом может быть стянуто через git pull.

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

git diff?

А как его можно увязать с post-receive-email? Чтобы не лезть в git, а пробегать глазами изменения непосредственно в почтовом клиенте.

«Хочешь чтоб было сделано хорошо - сделай сам»? :)

обычно это так) они ведь могут делать изменения и не делая git commit и/или git push

они ведь могут делать изменения и не делая git commit и/или git push

Замедление работы.

Чтоб не теоретизировать, опишу процесс. Работа идет с конфигом puppet, точнее с той его частью, в которой перечислены все ноды.

Процесс - развертывание клиентской машины.

• Специально обученный мальчик (low-level anykey) берет тачку, ставит на нее убунту с диска (а-ля «далее-далее-далее»).
• Ставит клиент puppet'а, отправляет запрос на сервер, принимает ключ клиента, типовая схема заведения клиента в паппет, в общем. На это ему дана инструкция в картинках.
• Лезет на сервак паппета, прописывает ноду в определенный список (в какой - ему говорится заранее).
• Коммитит данные в репозиторий на сервере, пушит в центральный репозиторий, опять же по инструкции в картинках. В принципе, тут и надо вешать post-recieve hook на центральный репозиторий, да и все, мне будет счастье.
• Запускает паппет на клиенте, тот всасывает все нужные настройки с сервера согласно тому списку, куда клиент прописан.
• Тачка отдается пользователю.

Т.е., вмешательство в конфиг хоть и минимально, но я всегда настраиваюсь на худшее и просматриваю дифф коммита, когда мне отзванивают и говорят, что машина отдана пользователю.

Я же в свою очередь, работаю с конфигом на своей локальной машине, внося какие-то более глобальные изменения, отсылая их в центральный репозиторий после тестирования и потом сдергивая их на боевой сервер с помощью git pull.

Ну да, получается, что мониторить репозиторий на боевом сервере нет смысла, достаточно мониторить центральный репозиторий, все равно все через него проходит.

А как его можно увязать с post-receive-email? Чтобы не лезть в git, а пробегать глазами изменения непосредственно в почтовом клиенте.

git config hooks.showrev

Сам спросил, сам ответил. Все есть в документации.

А как его можно увязать с post-receive-email?

Вызови его там, очевидно же. Всё в post-receive выполняется уже после наложения прилетевшего коммита.

Кстати, глянул, оно там и так есть
[code]
echo «Summary of changes:»
git diff-tree --stat --summary --find-copies-harder $oldrev..$newrev
[/code]
Чем не устраивает?

Да-да, там даже опция есть для этого, ниже написал. Задачу можно считать решенной.