Re: [PATCH] add a 'pre-push' hook
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 19, 2008, 22:23 UTC
- Message-ID
- <7vljysy78j.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <d411cc4a0808191445o22eb57b5tfaa37d715524f55a@mail.gmail.com>
"Scott Chacon" <schacon@gmail.com> writes:
Show 21 quoted lines
> 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.