Re: Fwd: Fwd: git-daemon access-hook race condition

2013-09-13 Thread Eugene Sajine
> > For now I'm trying to do the following: > > access-hook.bash has: > > delayed-notify.bash $@ & > > delayed-notify.bash has: > > sleep 10 > ... > curl ... > > 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

Re: Fwd: Fwd: git-daemon access-hook race condition

2013-09-12 Thread Junio C Hamano
Eugene Sajine writes: >> So even if we feed the exit status of the service process to the >> hook script specified by the --post-service-hook, it does not tell >> the script if the service "succeeded" in that sense. > > I see what you're saying. > In my particular use case I can work around that

Re: Fwd: Fwd: git-daemon access-hook race condition

2013-09-12 Thread Eugene Sajine
On Thu, Sep 12, 2013 at 6:20 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Eugene Sajine 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 daemo

Re: Fwd: Fwd: git-daemon access-hook race condition

2013-09-12 Thread Junio C Hamano
Junio C Hamano writes: > Eugene Sajine 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=:: > Every time a client co

Re: Fwd: Fwd: git-daemon access-hook race condition

2013-09-12 Thread Eugene Sajine
On Thu, Sep 12, 2013 at 5:16 PM, Eugene Sajine wrote: > 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

Re: Fwd: Fwd: git-daemon access-hook race condition

2013-09-12 Thread Eugene Sajine
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 wrote: > Eugene Sajine writ

Re: Fwd: Fwd: git-daemon access-hook race condition

2013-09-12 Thread Junio C Hamano
Eugene Sajine 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=:: Every time a client connects, first run an external command

Fwd: Fwd: git-daemon access-hook race condition

2013-09-12 Thread Eugene Sajine
On Thu, Sep 12, 2013 at 3:15 PM, Junio C Hamano wrote: > Eugene Sajine writes: > >> Is it possible to have access-hook to be executed after receive? > > The whole point of access-hook is to allow it to decide whether the > access is allowed or not, so that is a non-starter. > > A notification _af

Re: Fwd: git-daemon access-hook race condition

2013-09-12 Thread Junio C Hamano
Eugene Sajine writes: > Is it possible to have access-hook to be executed after receive? The whole point of access-hook is to allow it to decide whether the access is allowed or not, so that is a non-starter. A notification _after_ successful push update is usually done via the post-receive hoo

Fwd: git-daemon access-hook race condition

2013-09-12 Thread Eugene Sajine
Hi, We are serving repos in closed netwrok via git protocol. We are using git-daemon access hook (thank you very much for such a great feature) in order to create push notifications for Jenkins. I.e. upon the push the access-hook is called and then the curl command is created and executed. As we