Michael Haggerty <mhagger@xxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html