summaryrefslogtreecommitdiff
path: root/contrib/emacs
diff options
context:
space:
mode:
authorLibravatar Shawn O. Pearce <spearce@spearce.org>2007-04-20 02:08:47 -0400
committerLibravatar Junio C Hamano <junkio@cox.net>2007-04-19 23:27:09 -0700
commit9398e5aa1698cdb518f7118e6f6eeebbea7f5e58 (patch)
tree4204f7133be2b71356e046b08ed4264f99868876 /contrib/emacs
parentMerge branch 'maint' (diff)
downloadtgif-9398e5aa1698cdb518f7118e6f6eeebbea7f5e58.tar.xz
Contribute a fairly paranoid update hook
I'm using a variant of this update hook in a corporate environment where we perform some validations of the commits and tags that are being pushed. The model is a "central repository" type setup, where users are given access to push to specific branches within the shared central repository. In this particular installation we run a specially patched git-receive-pack in setuid mode via SSH, allowing all writes into the repository as the repository owner, but only if this hook blesses it. One of the major checks we perform with this hook is that the 'committer' line of a commit, or the 'tagger' line of a new annotated tag actually correlates to the UNIX user who is performing the push. Users can falsify these lines on their local repositories, but the central repository that management trusts will reject all such forgery attempts. Of course 'author' lines are still allowed to be any value, as sometimes changes do come from other individuals. Another nice feature of this hook is the access control lists for all repositories on the system can also be stored and tracked in a supporting Git repository, which can also be access controlled by itself. This allows full auditing of who-had-what-when-and-why, thanks to git-blame's data mining capabilities. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'contrib/emacs')
0 files changed, 0 insertions, 0 deletions