Давайте сразу начнут с ломом на pre-receive крючке, который я уже писал:Git и «ГИТ-лязг формат» сценарий надежно отклонить толчки, которые нарушают соглашения стиля кода
#!/bin/sh
##
format_bold='\033[1m'
format_red='\033[31m'
format_yellow='\033[33m'
format_normal='\033[0m'
##
format_error="${format_bold}${format_red}%s${format_normal}"
format_warning="${format_bold}${format_yellow}%s${format_normal}"
##
stdout() {
format="${1}"
shift
printf "${format}" "${@}"
}
##
stderr() {
stdout "${@}" 1>&2
}
##
output() {
format="${1}"
shift
stdout "${format}\n" "${@}"
}
##
error() {
format="${1}"
shift
stderr "${format_error}: ${format}\n" 'error' "${@}"
}
##
warning() {
format="${1}"
shift
stdout "${format_warning}: ${format}\n" 'warning' "${@}"
}
##
die() {
error "${@}"
exit 1
}
##
git() {
command git --no-pager "${@}"
}
##
list() {
git rev-list "${@}"
}
##
clang_format() {
git clang-format --style='file' "${@}"
}
##
while read sha1_old sha1_new ref; do
case "${ref}" in
refs/heads/*)
branch="$(expr "${ref}" : 'refs/heads/\(.*\)')"
if [ "$(expr "${sha1_new}" : '0*$')" -ne 0 ]; then # delete
unset sha1_new
# ...
else # update
if [ "$(expr "${sha1_old}" : '0*$')" -ne 0 ]; then # create
unset sha1_old
sha1_range="${sha1_new}"
else
sha1_range="${sha1_old}..${sha1_new}"
# ...
fi
fi
# ...
GIT_WORK_TREE="$(mktemp --tmpdir -d 'gitXXXXXX')"
export GIT_WORK_TREE
GIT_DIR="${GIT_WORK_TREE}/.git"
export GIT_DIR
mkdir -p "${GIT_DIR}"
cp -a * "${GIT_DIR}/"
ln -s "${PWD}/../.clang-format" "${GIT_WORK_TREE}/"
error=
for sha1 in $(list "${sha1_range}"); do
git checkout --force "${sha1}" > '/dev/null' 2>&1
if [ "$(list --count "${sha1}")" -eq 1 ]; then
# What should I put here?
else
git reset --soft 'HEAD~1' > '/dev/null' 2>&1
fi
diff="$(clang_format --diff)"
if [ "${diff%% *}" = 'diff' ]; then
error=1
error '%s: %s\n%s' \
'Code style issues detected' \
"${sha1}" \
"${diff}" \
1>&2
fi
done
if [ -n "${error}" ]; then
die '%s' 'Code style issues detected'
fi
fi
;;
refs/tags/*)
tag="$(expr "${ref}" : 'refs/tags/\(.*\)')"
# ...
;;
*)
# ...
;;
esac
done
exit 0
ПРИМЕЧАНИЕ.
Места с нерелевантным кодом обрезаны с # ....
Примечание:
Если вы не знакомы с git-clang-format, посмотрите here.
Этот крюк работает так, как ожидалось, и до сих пор я не заметил никаких ошибок, но если вы заметили какую-либо проблему или предложили улучшения, я был бы признателен за любой отчет. Вероятно, я должен дать комментарий о том, каково намерение этого крючка. Ну, он проверяет каждую нажатую ревизию на соответствие правилам стиля кода, используя git-clang-format, и, если какой-либо из них не соответствует, он выдаст соответствующий diff (тот, который говорит разработчикам, что нужно исправлять) для каждого из них. В принципе, у меня есть два подробных вопроса относительно этого крючка.
Прежде всего обратите внимание, что я выполняю копию голого репозитория удаленного сервера (сервера) в какой-либо временный каталог и проверяю там код для анализа. Позвольте мне объяснить намерение этого. Обратите внимание, что я делаю несколько git checkout и git reset s (из-за цикла for), чтобы проанализировать все сделанные изменения отдельно с помощью git-clang-format. То, что я пытаюсь избежать здесь, - это (возможная) проблема параллелизма при push-доступе к открытому репозиторию удаленного сервера (сервера). То есть, у меня создается впечатление, что если несколько разработчиков попытаются одновременно нажать на удаленный компьютер с установленным крючком pre-receive, это может вызвать проблемы, если каждый из этих push-сессий не выполняет git checkout s и git reset с его личная копия репозитория. Итак, проще говоря, имеет ли git-daemon встроенное управление блокировкой для одновременных push-сессий? Будут ли они выполнять соответствующие pre-receive экземпляры крючка строго последовательно или есть возможность чередования (что может потенциально вызвать неопределенное поведение)? Что-то подсказывает мне, что для этой проблемы должно быть встроенное решение с конкретными гарантиями, в противном случае, как бы удаленные работы вообще (даже без сложных перехватов) подвергались одновременным нажатиям? Если есть такое встроенное решение, то копия избыточна и просто повторное использование голого репозитория фактически ускорит обработку. Кстати, любая ссылка на официальную документацию по этому вопросу очень приветствуется.
Во-вторых, git-clang-format процессы только поставил (но не совершал) изменения по сравнению с конкретных фиксации (HEAD по умолчанию). Таким образом, вы можете легко увидеть, где находится угол. Да, это с корень совершает (ревизии). Фактически, git reset --soft 'HEAD~1' не может быть применен к корневым записям, поскольку у них нет родителей для перезагрузки. Следовательно, следующая проверка с моим вторым вопросом есть:
if [ "$(list --count "${sha1}")" -eq 1 ]; then
# What should I put here?
else
git reset --soft 'HEAD~1' > '/dev/null' 2>&1
fi
Я попытался git update-ref -d 'HEAD', но это ломает хранилище таким образом, чтобы git-clang-format не в состоянии обработать его больше. Я полагаю, что это связано с тем, что все эти подталкиваемые ревизии, которые анализируются (включая этот корень), пока не принадлежат ни одной отрасли. То есть, они находятся в отсоединеныHEAD состояние.Было бы неплохо найти решение этого углового случая, так что начальные коммиты могут также пройти ту же проверку на git-clang-format для соблюдения правил стиля кода.
Мир.