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