Re: How to use git attributes to configure server-side checks?

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 21, 2011, 20:17 UTC
Message-ID: <7vy5xh1whq.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4E7A3BDE.3040301@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 24 quoted lines

> I was thinking of using git attributes to configure a server-side
> "update" hook that does some basic sanity checking before accepting a
> push.  I thought I could do something like
>
> ~/.gitattributes:
>     *.c whitespace
>
> ~/crappy-vendor-code/.gitattributes:
>     # This code doesn't conform to our standards; disable check:
>     *.c -whitespace
>
> This would allow fine-grained specification of which checks are applied
> to which files, and ensure that the hook configuration is kept
> synchronized with changes to the content.
>
> What I can't figure out is how a server-side update hook can inquire
> about the gitattributes that were associated with a file *in a
> particular commit*, as opposed to in the current working tree.  I would
> like to ask questions like "was the "whitespace" attribute set on file F
> in commit C?"
>
> I see that there is an (undocumented) API involving
> git_attr_set_direction() that seems to let gitattributes to be read out
> of the index instead of the working tree.  But I am still confused:

The words "server side" automatically mean that there should be no working tree, and where there is no working tree there should be no index, so the direction should not make any difference. The attributes that are used to help whitespace checks should come from project.git/info/attributes in such a case [*1*].

As to the actual checking of the pushed contents, your pre-receive hook is called after all the objects received are placed in the object store, but before the refs are updated to conclude the push, and you can veto the push by exiting with non-zero status from the hook. Your hook will get which ref is being updated from what old commit to what new commit, so you can either

 (1) grab the new commits introduced to the project using rev-list, and
     invoke "git show --check" on each and every one of them; or

 (2) check only the endpoints, by running "git diff --check" between the
     old and new commits. A pushed series may introduce a breakage early
     in the series which is corrected later in the series and you would
     not catch such a case if you used this method.

[Footnote]

*1* granted, that there are people who make a checkout from their post update hook, perhaps so that a build robot can be told to work on it or the web server can deliver individual files. But that is merely a crude substitute of having a proper "install" procedure. As far as the "server-side" Git that accepts "git push" is concerned, such a working tree does not exist.