On Mon, Nov 28, 2011 at 12:11 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Sitaram Chamarty <sitaramc@xxxxxxxxx> 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. > 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. -- 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