Are git pre-receive/update hooks serialized?

I'm investigating the possibility of implementing a "pre-commit" verification flow, enforced on the central SCM server side. By "pre-commit" in this paragraph I don't mean the git pre-commit hook, I really mean before the change becomes part of the integration branch, visible to all developers working on the branch.

For git in particular, which is a distributed SCM, the commit phase happens on the local server, which is not what I need. So I can't use the git pre-commit hook.

From what I gather the pre-receive hook would be what I'm after:


This hook is invoked by 'git-receive-pack' on the remote repository,
which happens when a 'git push' is done on a local repository. Just
before starting to update refs on the remote repository, the
pre-receive hook is invoked. Its exit status determines the success
or failure of the update.


This hook executes once for the receive operation. [snip]


If the hook exits with non-zero status, none of the refs will be
updated. If the hook exits with zero, updating of individual refs can
still be prevented by the > hook.

Or maybe the related update hook:


This hook is invoked by 'git-receive-pack' on the remote repository,
which happens when a 'git push' is done on a local repository. Just
before updating the ref on the remote repository, the update hook is
invoked. Its exit status determines the success or failure of the ref
update.


The hook executes once for each ref to be updated, [snip]

The complication is that the verification itself can take a while.

My question: is the execution of these hooks serialized (by git)? Meaning will another hook invocation (due to a subsequent push operation performed before the previous hook execution completes):

• fail,

• block until the previous, still running execution finishes,

or

• simply run in parallel with the previous hook execution?

In general git allows concurrent operations because one of them will eventually fail. Some specific database updates will have file locks (like updating the index files) but multiple receives can be in flight at once I think. In this case whichever verification completed first would be allowed in, and the second would fail due to having an invalid history (i.e. not being a fast-forward push).

In general this kind of operation is not well suited to git's server-side hooks since if something does fail, the person will then have to do some surgery on their branches to get things back in a valid state. These kinds of checks are generally run on the workstation side, though then you run into the "fun" that is distributing git hooks as they can't actually be checked in directly.

Another common solution is to have a CI service like Jenkins running verifications (tests) and updating a second branch or a utility tag showing which commits are acceptable.

StackExchange DevOps Q#431, answer score: 3