Запретить оформление заказа в Git

Question

В настоящее время я изучаю управление исходным кодом из приложения OpenInsight с помощью Git. Поскольку код OI хранится в таблице базы данных, существует определенный объем ручной работы для экспорта источника в текст и наоборот.

До сих пор мне удалось автоматизировать большую часть этой работы с помощью хитов Git, но отсутствие хука "предварительной проверки" поставило меня перед проблемой..

Когда пользователь переключает ветки, у меня есть ловушка после оформления заказа, чтобы различать старые и новые ветви и сохранять список измененных процедур. Когда пользователь в следующий раз запускает OI, изменения извлекаются из текстовых файлов и компилируются... пока все хорошо. Однако если пользователь должен был переключать ветви, скажем, от A до B, а затем снова переключиться на C, не запуская OI, тогда источник в OI будет для ветви A, но разница будет между B и C.

Чтобы обойти это, я надеялся использовать ловушку предварительной проверки, чтобы проверить наличие файла, содержащего список нескомпилированных изменений, и остановить переключение пользовательских веток до тех пор, пока они не будут скомпилированы. Есть ли другие предложения способы остановки проверки?

Answer 1

Я также изучал это недавно и нашел поток, обсуждающий текущее (хорошо... 2010) состояние githooks

http://git.661346.n2.nabble.com/Why-there-is-no-pre-checkout-hook-td5638042.html

Из темы:

Оскар Фуэнтес написал:
...
Потому что вы можете использовать свой скрипт вместо "git checkout".

Рассматривали ли вы написание сценария, который разработчики могут сделать частью своего рабочего процесса? Таким образом, вы можете проверить наличие не скомпилированного списка изменений. Это в основном то, что мы в итоге сделали, и это действительно помогло нам упростить / стандартизировать наш рабочий процесс.

Answer 2

Ваша проблема в том, что вы делаете неправильные различия.

Однако, если пользователь должен переключить ветви, скажем, с A на B, а затем снова переключиться на C без запуска OI, тогда источник в OI будет для ветви A, но разница будет между B и C.

Вы основываете свои diff revs на активности git, когда сами говорите, что должны основывать их на своих запусках OI.

Итак, перехватите OI, проверьте обороты головы, разницу между тем, что было в прошлый раз, и тем, что было на этот раз.