Re: what are the chances of a 'pre-upload' hook?

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Nov 28, 2011, 08:17 UTC
Message-ID: <CAMK1S_hX3fEf1nL28yxASLw_cveJbC5aQRdixgBF6zaPyAEsdA@mail.gmail.com>
In-Reply-To: <7vzkfgvjdo.fsf@alter.siamese.dyndns.org>

On Mon, Nov 28, 2011 at 12:11 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 12 quoted lines

> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>>> 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.

Because I did not think it was so complicated...? :-)

> 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.

Show 6 quoted lines

> 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.

There are only 2 cases: git-upload-pack runs as invoking user, or it runs as some common user/repo owner.

I see pre-upload hooks for case 1 as being hard/impossible to do, while case 2 is trivial (just check if the hook file owner == UID of the git-upload-pack process).

Yes, this means pre-upload won't work identically in *all* setups. But as you said somewhere: perfect is the enemy of good.