Re: what are the chances of a 'pre-upload' hook?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 28, 2011, 06:41 UTC
- Message-ID
- <7vzkfgvjdo.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CAMK1S_jbofsWyag3Sospz8wYHqD4Z1Fs0p+MJWi02eCq0e+uHQ@mail.gmail.com>
Sitaram Chamarty <sitaramc@gmail.com> writes:
Show 7 quoted lines
>> I actually like the idea of allowing pre-upload-pack hook on git:// and >> possibly http:// only.... >> >> One scenario I do not want to see is this. Suppose ... > > I'm sorry I started this discussion. I worked around it, though it's > a bit kludgy, so maybe time to drop the debate.
I do not want you to feel sorry, and I do not understand why you feel that way.
I think a reasonable and safe way to trigger an action in response to a request to fetch from a repository _is_ a sensible thing to wish for. So far, we established that we cannot just simply add pre-upload hook back in and be done with it, as that is not a safe way. We learned something.
Jeff may be right that any approach based on hooks cannot be made totally safe. But the discussion can lead to a workable alternative. The "enable the hook only on git:// and http:// and no other" approach might or might not be such a workable alternative. The "try talking to a service process via named pipe, instead of spawning a hook" might or might not be such a workable alternative. Other possibilities may be there to be explored.