Daniel Barkalow [off-list ref] writes:
quoted
My immediate reaction was "do not do it then", but you are
right. Hooks are run after all the protocol exchanges are done,
so they should be free to throw any garbage at the other end.
If we extend it to transfer multiple things, wouldn't we want to run hooks
after each of them, rather than all at the end?
We do transfer multiple things already, and all protocol
exchange happens before everything is transferred. And hooks
are run for each refs being updated, one by one. What we do not
have is a reporting mechanism that says "we refused to update
this ref because of the hooks/update policy return value for
it". Even if we later add that reporting mechanism, as I
outlined in a separate message earlier, I think it is OK to keep
running the update hooks after the pack transfer part.
As for the policy:
We definitely want to let hooks write to stdout, because git programs that
you might want to run in hooks write to stdout.
... I'd sort of like to avoid making people expect that there
is necessarily a path for text going back to the user directly.
... I
also think that messages are likely to be at least as useful to the owner
of the target repository as the person pushing, which is why I'd prefer a
log file.
This part I mostly agree with. Will have to think about the
details but probably I'd punt this for now and declare it post
1.0 ;-).
On Mon, 19 Dec 2005, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
quoted
My immediate reaction was "do not do it then", but you are
right. Hooks are run after all the protocol exchanges are done,
so they should be free to throw any garbage at the other end.
If we extend it to transfer multiple things, wouldn't we want to run hooks
after each of them, rather than all at the end?
We do transfer multiple things already, and all protocol
exchange happens before everything is transferred. And hooks
are run for each refs being updated, one by one. What we do not
have is a reporting mechanism that says "we refused to update
this ref because of the hooks/update policy return value for
it". Even if we later add that reporting mechanism, as I
outlined in a separate message earlier, I think it is OK to keep
running the update hooks after the pack transfer part.
If we have the reporting mechanism, that will effectively be part of the
protocol. It's obviously done transferring the pack at that point, but it
still wants fixed-format communication, so switching over to being the
stardard output of the hooks would cause problems with this.
quoted
As for the policy:
We definitely want to let hooks write to stdout, because git programs that
you might want to run in hooks write to stdout.
... I'd sort of like to avoid making people expect that there
is necessarily a path for text going back to the user directly.
... I
also think that messages are likely to be at least as useful to the owner
of the target repository as the person pushing, which is why I'd prefer a
log file.
This part I mostly agree with. Will have to think about the
details but probably I'd punt this for now and declare it post
1.0 ;-).
It's probably worth making sure that all the hooks run with something
sane, and punt making it configurable andnice until post-1.0. I was only
really looking at post-update, so I don't know how the others run.
-Daniel
*This .sig left intentionally blank*