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
pre-commit hook, I really mean before the change becomes part of the integration branch, visible to all developers working on the branch.
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
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
Or maybe the related
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):
- block until the previous, still running execution finishes,
- simply run in parallel with the previous hook execution?