Hi, On Wed, 26 Aug 2009, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Tue, 25 Aug 2009, Junio C Hamano wrote: > > > >> and if one of the primary reason for this new hook is statistics, it > >> would be useful to see the number of bytes given, where the > >> fetch-pack came from, and if we are using git-daemon virtual hosting > >> which of our domain served the request. > > > > Certainly those are possible add-on patches, but would you require > > them to be in the same commit? > > I was merely responding to the "what else would be useful" question posed > by Peff. Sure. > Did you get an impression that I was saying "you must add these > otherwise I'll reject the patch"? Well, I got the impression that you'd not accept the patch without additional information given by the hook, and I got the impression that Tom would decide as a consequence to rather live with his eternal fork instead of working on getting this patch included. > It might make sense to define the external interface to be "information > is given through the standard input of the hook, formatted in YAML, and > here are the initial set of items that may be fed", so that we do not > have to worry about the details too much. Hmm. You bring up YAML a few times recently, it seems, but I think this is not what you are meaning. In this case, you'd need to have a simple enquiry system that asks for some information and receives it as a response. But I would find it utterly overengineered if upload-pack would support something as complicated as that. IMHO either upload-pack knows already about the information, or the script has to try to discover it using Git commands itself. My conclusion: I _think_ it would make sense to pass the name of the pack file(s) created by upload-pack to the hook, or something similar, but nothing more. Well, _maybe_ the byte count of the protocol exchange and the IP. But nothing that requires calculations. Ciao, Dscho -- 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