Git“预接收”挂钩和“git-clang-format”脚本可以可靠地拒绝违反代码风格约定的推送

让我们立即从一个片段开始pre-receive我已经写过的钩子：

#!/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

NOTE:
不相关代码的地方会被删除# ....

NOTE:
如果您不熟悉git-clang-format， 看一看here http://llvm.org/svn/llvm-project/cfe/trunk/tools/clang-format/git-clang-format.

该钩子按预期工作，到目前为止，我没有发现任何错误，但如果您发现任何问题或有改进建议，我将不胜感激。也许，我应该对这个钩子背后的意图发表评论。嗯，它确实检查每个推送的修订版本是否符合代码风格约定，使用git-clang-format，如果其中任何一个不符合，它将为每个输出输出相关的差异（告诉开发人员应该修复什么）。基本上，我有两个关于这个钩子的深入问题。

首先，请注意，我将远程（服务器）裸存储库复制到某个临时目录，并在那里检查代码以进行分析。让我解释一下这样做的意图。请注意，我做了几个git checkouts and git resets（由于for循环）以便单独分析所有推送的修订git-clang-format。我在这里试图避免的是推送访问远程（服务器）裸存储库时出现的（可能的）并发问题。也就是说，我的印象是，如果多个开发人员尝试使用此方法同时推送到远程pre-receive安装了钩子，如果每个推送“会话”不执行，可能会导致问题git checkouts and git resets 及其存储库的私有副本。所以，简单来说，git-daemon是否有针对并发推送“会话”的内置锁管理？是否会执行相应的pre-receive严格按顺序挂钩实例还是有可能交错（这可能会导致未定义的行为）？有些东西告诉我，应该有一个内置的解决方案来解决这个问题并提供具体的保证，否则远程设备在并发推送时一般如何工作（即使没有复杂的钩子）？如果有这样的内置解决方案，那么副本就是多余的，简单地重用裸存储库实际上会加快处理速度。顺便说一句，非常欢迎任何有关此问题的官方文档的参考。

Second, git-clang-format仅处理staged（但未提交）更改与特定提交（HEAD默认情况下）。因此，您可以轻松地看到极端情况所在。是的，它与root提交（修订）。实际上，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无法再处理它了。我相信这与以下事实有关：所有这些正在分析的推送修订（包括这个根修订）实际上并不属于任何分支。也就是说，他们在detached HEAD状态。找到这个极端情况的解决方案也是完美的，这样initial提交也可以接受相同的检查git-clang-format以符合代码风格约定。

Peace.

NOTE:
对于那些寻找最新的、（或多或少）全面且经过充分测试的解决方案的人，我托管相应的公共存储库 [1 http://bitbucket.Alexander.Shukaev.name/git-hooks]。目前，两个重要的钩子依赖于git-clang-format已实施：pre-commit and pre-receive。理想情况下，同时使用它们时，您可以获得最自动化和最简单的工作流程。与往常一样，我们非常欢迎提出改进建议。

NOTE:
目前，pre-commit hook [1 http://bitbucket.Alexander.Shukaev.name/git-hooks] 要求git-clang-format.diff补丁（也是我写的）[1 http://bitbucket.Alexander.Shukaev.name/git-hooks] 应用于git-clang-format。该补丁的动机和用例示例总结在提交给 LLVM/Clang 的官方补丁审查中 [2 http://reviews.llvm.org/D15465]。希望它很快就会被上游接受并合并。

我已经设法实现第二个问题的解决方案。我不得不承认，由于 Git 文档稀少且缺乏示例，所以很难找到它。我们先看一下对应的代码改动：

# ...
clang_format() {
  git clang-format --commit="${commit}" --style='file' "${@}"
}
# ...
      for sha1 in $(list "${sha1_range}"); do
        git checkout --force "${sha1}" > '/dev/null' 2>&1
        if [ "$(list --count "${sha1}")" -eq 1 ]; then
          commit='4b825dc642cb6eb9a060e54bf8d69288fbee4904'
        else
          commit='HEAD~1'
        fi
        diff="$(clang_format --diff)"
        # ...
      done
      # ...

正如你所看到的，而不是重复做git reset --soft 'HEAD~1'，我现在明确指示git-clang-format进行操作HEAD~1与--commit选项（而其默认值是HEAD这在我的问题中提出的初始版本中有所暗示）。然而，这仍然不能单独解决问题，因为当我们遇到root提交这将再次导致错误，如下所示HEAD~1将不再引用有效的修订版（类似于不可能执行的操作）git reset --soft 'HEAD~1'）。这就是为什么对于这个特殊情况，我指示git-clang-format对抗（魔法）4b825dc642cb6eb9a060e54bf8d69288fbee4904 hash [3 http://colinschimmelfing.com/blog/gits-empty-tree/, 4 https://stackoverflow.com/q/9765453/1743860, 5 http://git.wiki.kernel.org/index.php/Aliases#Obtaining_the_Empty_Tree_SHA1, 6 http://comments.gmane.org/gmane.comp.version-control.git/180511]。要了解有关此哈希的更多信息，请查阅参考资料，但简而言之，它指的是 Git空树对象— 没有任何上演或承诺的内容，这正是我们所需要的git-clang-format在我们的例子中进行操作。

NOTE:
你不必记住4b825dc642cb6eb9a060e54bf8d69288fbee4904用心记住，最好不要对其进行硬编码（以防万一这个神奇的哈希值将来会发生变化）。事实证明，它总是可以检索git hash-object -t tree '/dev/null' [5 http://git.wiki.kernel.org/index.php/Aliases#Obtaining_the_Empty_Tree_SHA1, 6 http://comments.gmane.org/gmane.comp.version-control.git/180511]。因此，在我上述的最终版本中pre-receive钩子，我有commit="$(git hash-object -t tree '/dev/null')"反而。

P.S.我仍在寻找第一个问题的高质量答案。顺便说一句，我在官方 Git 邮件列表上提出了这些问题，但到目前为止还没有收到答案，真是遗憾......