Re: [PATCH] add a 'pre-push' hook

[Junio C Hamano <gitster@pobox.com>]

"Scott Chacon" <schacon@gmail.com> writes:

> On Tue, Aug 19, 2008 at 2:26 PM, しらいしななこ <nanako3@lavabit.com> wrote:
>> Quoting Scott Chacon <schacon@gmail.com>:
>>
>>> I thought the point of these kind of hooks was to make stuff like this
>>> automatic and easy to standardize for a project, so people working on
>>> a dozen git repos don't have to remember all the aliases they set up
>>> in each one.
>>
>> This topic seems to come up every once in a while.
>>
>>  http://thread.gmane.org/gmane.comp.version-control.git/70781/focus=71069
>>  http://thread.gmane.org/gmane.comp.version-control.git/79306/focus=79321
>>
>> Somebody needs to describe the general rules in SubmittingPatches, perhaps?
>>
>> I do not understand why Junio said he thinks this pre-push hook is a good idea.  This clearly is "you always would want to do before running a git command" case.
>
> I don't think I understand how this is different than 'pre-commit'
> (or, alternatively, how this does not fall under #1 in that list).  If
> the script exits non-0, it stops the push, isn't that exactly what
> pre-commit does, but with 'push' instead of 'commit'?

[jc: trimmed excessive quotes --- please don't quote e-mail sigs]

The primary reason I said it would be a good thing to have is that it
could be common enough.

On one hand, the fact that this pre-push proposal came very late after
everybody used "git push" for eternity might mean that this is not common
requirement at all, and the wrapper approach Shawn and Jeff suggested may
be the right thing to do for minorities who want it.

The pre-commit hook has a good reason behind its existence than merely
being a "pre-something" hook that interferes.  If you only think about
"git commit -a" run by the end user, yes, the whole working tree can be
validated by your wrapper script before making the commit without any need
for a hook, but the user can also say "git commit this-path-only" and give
other options, and at that point, a wrapper approach would not fly well
unless your wrapper simulates what the underlying "git commit" would do
given the set of parameters.

Similarly, a pre-push hook, if done correctly, needs to see what is about
to be pushed (e.g. the user may only say "git push" without saying where
to push to and what ref to update with which commit) to base its
validation decision on, but that cannot be easily checked without actually
simulating the push.  IOW, it has criteria (2) component in it as well,
just like pre-commit hook does.