On Tue, Aug 19, 2008 at 12:59 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > Jeff King <peff@xxxxxxxx> wrote: >> I think the common wisdom has been that such tests should be done on the >> _receiving_ end, since that makes a more trustworthy enforcement point. >> E.g., I know that crap can't get into my central repo because a hook >> checks everything coming in. But if a developer has turned off his >> pre-push hook (or accidentally failed to enable it), he can still send >> crap. >> >> One other argument I have seen is that, to prevent the proliferation of >> hooks, the rule is not to add a hook that could just as easily be done >> as a sequence of commands. IOW, what's wrong with >> >> run_my_automated_tests && git push > > Yup, I agree completely. > > Why not just setup an alias: > > git config alias.send '! run_my_tests && git push "$@"' > > and retrain your fingers to use "git send ..."? > > -- > Shawn. Sorry, but couldn't this argument be made about any of the hooks run after manual operations? ie: pre-commit, pre-applypatch, commit-msg, post-commit, post-applypatch? I mean, couldn't you do : git config alias.docommit '! do_pre_commit && git commit ...' ? 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. Scott -- 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
