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:
1. The "git check-attr" program doesn't seem to expose the
git_attr_set_direction() functionality.
2. Even if it did, would that be enough? It seems like the update hook
(assuming a bare repository) would have to "git reset" the index to the
commit that it wants to check. Is that allowed? Is the index a scratch
space that the update hook can use however it likes? If so, is there
some kind of locking that would prevent multiple simultaneous pushes
from overwriting each other's index stat, or would the update script
have to implement its own locking scheme?
Am I going about this entirely the wrong way?
Thanks,
Michael
--
Michael Haggerty
mhagger@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
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