From: Junio C Hamano Date: Tue, 06 Dec 2011 01:39:19 GMT Subject: Re: hooks that do not consume stdin sometimes crash git with SIGPIPE Message-ID: <7vmxb6iim0.fsf@alter.siamese.dyndns.org> In-Reply-To: <20111205192930.GA32463@gnu.kitenet.net> Joey Hess writes: > We had a weird problem where, after moving to a new, faster server, > "git push" would sometimes fail like this: > > Unpacking objects: 100% (3/3), done. > fatal: The remote end hung up unexpectedly > fatal: The remote end hung up unexpectedly > > Turns out that git-receive-pack was dying due to an uncaught SIGPIPE. Why do you have a hook that is expected to read from receive-pack that does _not_ read anything from it in the first place? If you do not care about the update status given to pre-receive, shouldn't you be using the update hook and ignoring the command line parameters instead? I am not saying this is a user configuration error and there is nothing to fix---Git shouldn't get killed merely because of configuration error. I am wondering if we would want to have a uniform way to tell run_*_hook() functions that the hook writer explicitly declines to get any input. E.g. "hooks/pre-receive-noinput" is called instead of "hooks/pre-receive" and we do not send any input to it, or something like that.