On Sat, Nov 26, 2011 at 03:13:38PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > Bob could run a specialized server for (b) that listens on a unix socket > > and triggers his hook. But why? Why not just do the whole thing over > > git-daemon or smart http, which already exist? > > If that "whole thing" is "to allow an arbitrary code to run anywhere as > incoming user", I would apply the "why?" to a different part of the > statemennt. Why allow running an arbitrary code at all? Because there are useful hooks that Bob wants to run when somebody fetches or pushes to/from his repository? > A pre-anything hook wants to see if the accessing user, not the owner of > the repository, can or cannot do something to the repository and decide > what to do. It depends on what you want your hook to do. I thought Sitaram's use-case was putting something like "git fetch upstream" into a hook that runs before upload-pack, to create a transparent proxy. That has nothing to do with the accessing user. At GitHub, we run a pre-upload-pack hook to keep statistics. That has nothing to do with the accessing user. We have to patch git to provide the hook. And even if you _did_ want to know something about the accessing user, that doesn't mean you necessarily can or want to be running code as them. If I'm running a smart-http server, I might have verified the user already via cookie, client cert, or basic auth. That information could be passed down to a pre-upload-pack hook where it could make a decision. But we don't _have_ a pre-upload-pack hook, because it can be dangerous in some situations. My point is to make it available, give it safe semantics by default, and let people who are running daemon-like service (i.e., where the admin controls the daemon and arbitrary users can't write into the hooks directory) use it by setting an environment variable, rather than patching git. -Peff -- 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