What's the difference between post-receive and post-update?

Question

I want to update a bare repo, and have it do something after something has been pushed to it using a hook. Which one should I use? The git-scm book says that they both fire after all refs have been updated, so I don't know what the difference is.

Answer 1

From the documentation:

post-receive:

This supersedes the <post-update> hook in that it gets both old and new values of all the refs in addition to their names.

post-update:

The 'post-update' hook can tell what are the heads that were pushed, but it does not know what their original and updated values are, so it is a poor place to do log old..new. The <post-receive> hook does get both original and updated values of the refs. You might consider it instead if you need them.

Answer 2

A recent commit for Git 2.2+ (November 2014), by Junio C Hamano (gitster) do mention:

The pre-receive and post-receive hooks were designed to be an improvement over old style update and post-update hooks, which take the update information on their command line and are limited by the command line length limit.

The same information is fed from the standard input to pre/post-receive hooks instead to lift this limitation.

It has been mandatory for these new style hooks to consume the update information fully from the standard input stream. Otherwise, they would risk killing the receive-pack process via SIGPIPE.

It now adds:

If a hook does not want to look at all the information, it is easy to send its standard input to /dev/null (perhaps a niche use of hook might need to know only the fact that a push was made, without having to know what objects have been pushed to update which refs), and this has already been done by existing hooks that are written carefully.

However, because there is no good way to consistently fail hooks that do not consume the input fully (a small push may result in a short update record that may fit within the pipe buffer, to which the receive-pack process may manage to write before the hook has a chance to exit without reading anything, which will not result in a death-by-SIGPIPE of receive-pack), it can lead to a hard to diagnose "once in a blue moon" phantom failure.

Lift this "hooks must consume their input fully" mandate.