Jeff King <peff@xxxxxxxx> writes: > 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. I personally have a huge problem with shipping an inherently unsafe mechanism that is disabled by default even if it is marked with big red letters saying that it is unsafe and should not be enabled casually. It makes it up to the system administrator to decide what is casual and what is not, but when end users are get harmed by a clueless administrator's decision, the repercussion will come back to the Git software, not to the clueless administrator who enabled an unsafe mechanism in an environment where it was not designed to support. It may merely be a matter of perception. After all, the pre-upload-pack hook I did in a8563ec (upload-pack: add a trigger for post-upload-pack hook, 2009-08-26) in response to GitHub's stat request was so trivial that even clueless admins could trojan it back into the current upload-pack source to use in their own site, without letting their users know that their fetch request may be opening their account to a random hook script. So in that sense, it might not be worth my effort to fight for Git users' safety to find a better solution and instead go with the big red letter approach which is easy. I know perfect is an enemy of good, but when I do not think an easy Quick-and-Dirty solution is even less than good, I need to point out that not having less than bad is better than having it. If the mechanism to notify the external machinery (i.e. counting accesses, learning the true destination of a new fetch request and have the fetcher wait while the real fetch goes to the origin site) were not via a hook that runs as the fetcher but were via something else that runs as the owner of that external service (i.e. counting accesses, maintaining the proxy object pool), I wouldn't have trouble with the proposal. For example, upload-pack could write the details of the original request to a named pipe to ask the "service" process listening on the other end, and wait for its response. -- 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