Joey Hess <joey@xxxxxxxxxxx> 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. -- 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