On Thu, Sep 12, 2013 at 5:16 PM, Eugene Sajine <eugu...@gmail.com> wrote:
> 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!
> On Thu, Sep 12, 2013 at 5:08 PM, Junio C Hamano <gits...@pobox.com> wrote:
>> Eugene Sajine <eugu...@gmail.com> 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":
>> 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.
For now I'm trying to do the following:
delayed-notify.bash $@ &
I'm expecting access-hook to spawn new process and return without
waiting for it to finish to let the service to do its job. But when i
do push - it sleeps for 10 seconds anyway. Am i missing something
Any help is much appreciated!
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html