Git 'pre-receive' hook and 'git-clang-format' script to reliably reject pushes that violate code style conventions

NOTE:
For those looking for an up-to-date, (more or less) comprehensive, and well-tested solution, I host the corresponding public repository [1]. Currently, the two important hooks relying on git-clang-format are implemented: pre-commit and pre-receive. Ideally, you get the most automation and fool-proof workflow when using both of them simultaneously. As usual, improvement suggestions are very welcome.

NOTE:
Currently, the pre-commit hook [1] requires the git-clang-format.diff patch (authored by me as well) [1] to be applied to git-clang-format. The motivation and use case examples for this patch are summarized in the official patch review submission to LLVM/Clang [2]. Hopefully, it will be accepted and merged upstream soon.

---

I've managed to implement a solution for the second question. I have to admit that it was not easy to find due to scarce Git documentation and absence of examples. Let's take a look at the corresponding code changes first:

# ...
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
      # ...

As you can see, instead of repeatedly doing git reset --soft 'HEAD~1', I now explicitly instruct git-clang-format to operate against HEAD~1 with the --commit option (whereas its default is HEAD that was implied in the initial version presented in my question). However, that still does not solve the problem on its own because when we would hit root commit this would again result in error as HEAD~1 would not refer to a valid revision anymore (similarly to how it would not be possible to do git reset --soft 'HEAD~1'). That's why for this particular case, I instruct git-clang-format to operate against the (magic) 4b825dc642cb6eb9a060e54bf8d69288fbee4904 hash [3, 4, 5, 6]. To learn more about this hash, consult the references, but, in brief, it refers to the Git empty tree object — the one that has nothing staged or committed, which is exactly what we need git-clang-format to operate against in our case.

NOTE:
You don't have to remember 4b825dc642cb6eb9a060e54bf8d69288fbee4904 by heart and it's better not to hard code it (just in case this magic hash ever changes in future). It turns out that it can always be retrieved with git hash-object -t tree '/dev/null' [5, 6]. Thus, in my final version of the above pre-receive hook, I have commit="$(git hash-object -t tree '/dev/null')" instead.

P.S. I'm still looking for a good quality answer on my first question. By the way, I asked these questions on the official Git mailing list and received no answers so far, what a shame...