threads / discuss / 38243

GIT_PUSH_CERT* env vars and update/post-update hooks...

Subject: GIT_PUSH_CERT* env vars and update/post-update hooks...

## tl;dr

2 messages between Dec 24, 2014 and Dec 29, 2014.

replies: 1people: 2as markdown or json

Sitaram Chamarty· Dec 24, 2014, 01:57 UTC · lore
Hi git core devs,

Any chance I could persuade you to set the GIT_PUSH_CERT* environment variables for the update (and post-update) hooks also?

Background: gitolite "takes over" the update hook [1] for authorisation
and enforcement, and I want to avoid taking over the pre-receive hook
also in order to do this check.

The post-update is not so important; gitolite doesn't use it anyway, so if I have to take over one of them, I may as well take over post-receive. I just added that for consistency.

thanks sitaram

[1]: because it's nice to *selectively* reject refs when more than one ref is pushed at the same time; pre-receive is "all or none".

Junio C Hamano· Dec 29, 2014, 16:36 UTC · re: Sitaram Chamarty · lore

Re: GIT_PUSH_CERT* env vars and update/post-update hooks...

Sitaram Chamarty <sitaramc@gmail.com> writes:
> Any chance I could persuade you to set the GIT_PUSH_CERT* environment
> variables for the update (and post-update) hooks also?

I do not think of a fundamental reason why we shouldn't give these environment variables to update or other hooks. It should just be the matter of calling prepare_push_cert_sha1() on the child_process struct used to run the hooks you want.

> [1]: because it's nice to *selectively* reject refs when more than one
> ref is pushed at the same time; pre-receive is "all or none".

It cuts both ways; inside "update", your "selective" rejection cannot make the decision with the whole picture (you only have a peephole into individual changes). "post-receive" sees the whole picture, but it has to say all-or-none. Neither is ideal if you truly want a useful "selective".

← back to recent threads