Junio, Thanks for the clarification! Your solution does look better. For now though i think i will have to delay the notification somehow and let the service finish first then notify the server. Thanks again! Eugene On Thu, Sep 12, 2013 at 5:08 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Eugene Sajine <euguess@xxxxxxxxx> writes: > >> So are you really sure that it is a non-starter to have >> --before-service/--after-service options for access-hook? > > Given the definition of "--access-hook" in "git help daemon": > > --access-hook=<path>:: > Every time a client connects, first run an external command > specified by the <path> ... The external command can decide > to decline the service by exiting with a non-zero status (or > to allow it by exiting with a zero status).... > > There is *NO* way in anywhere --after-service makes any sense (and > by definition --before-service is redundant). > > What you _could_ propose is to define a *new* hook that is run when > the spawned service has returned, with the same information that is > fed to the access hook (possibly with its exit status). > > I do not offhand know if we retain the original service information > that long after the main daemon process has spawned the service > process, though. With the current system, the only thing it needs > to know is the PID of the service processes that are to be culled by > calls to waitpid(). So you may have to extend existing bookkeeping > data structures a bit to keep those pieces of information around if > you wanted to add such a new hook. > > -- 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