Re: [PATCH] Fix race and deadlock when sending pack

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Dec 19, 2005, 18:40 UTC
Message-ID: <Pine.LNX.4.64.0512191236290.25300@iabervon.org>
In-Reply-To: <7vzmmxlkbq.fsf@assigned-by-dhcp.cox.net>

On Sun, 18 Dec 2005, Junio C Hamano wrote:

Show 12 quoted lines

> Paul Serice <paul@serice.net> writes:
> 
> > The best way to reproduce the problem is to locally clone your
> > repository.  When you perform a push, git-send-pack will directly set
> > up pipes connected to stdin and stdout of git-receive-pack.  You
> > should then set up hook/post-update or hook/update to try to write
> > lots of text to stdout.  (You want to use the local protocol because
> > ssh is robust enough to mask the worst behavior.)
> 
> 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?

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 can't figure out what "cvs" does with trigger script output and "at" and "cron" email the output to the owners. I'd sort of like to avoid making people expect that there is necessarily a path for text going back to the user directly. We may, for example, want to support these hooks with pushes over HTTP(/WebDAV). 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. E.g., if you've got a group central repository that different people push to, it may be other group members who want to know what happened with the output from a post-update hook, not the group member who pushed.

	-Daniel
*This .sig left intentionally blank*