Re: [PATCH 0/4] pre-push hook support

Aaron Schrab [off-list ref] writes:

There have been at least a couple of submissions to add support for a
pre-push hook, which were rejected at least partially because they didn't
provide enough information to a hook script for it to determine what was
to be pushed any better than a separate wrapper around the 'git push'
command would be able to do.  In this series I attempt to address that
problem.

The first two patches in this series do a little bit of refactoring in
order to make it easier to call hooks with a variable number of arguments.

The third patch actually adds support for calling a pre-push hook.  If it
exists, it will be called with the name and URL of the destination remote
(if a named remote isn't being used, the URL will be supplied for both)
followed by another argument for each ref being pushed; these arguments
take the form:

  <local ref>:<local sha1>:<remote ref>:<remote sha1>

One lesson we learned long time ago while doing hooks is to avoid
unbound number of command line arguments and instead feed them from
the standard input.  I think this should do the same.

This should provide enough information for a script to easily determine
the set of commits that is being pushed, and thus make a decision if that
should be allowed.

How does the hook communicate its decision to the calling Git?

Will it be "all-or-none", or "I'll allow these but not those"?