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

Michael Haggerty [off-list ref] writes:

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.