On 2 May 2012 12:27, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> writes: > >> On 1 May 2012 23:38, Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: >> ... >>> Yes, but at least, you have the opportunity to examine the other places >>> before they are ran. Hooks would be really, really nasty security-wise. >>> For example, "git clone" does a checkout, so should probably run the >>> checkout hooks. >> >> There is (or, rather, should be) absolutely no difference between code >> changes and hook changes. Both would go through the same review >> process. > > Matthieu is *not* talking about auditing nastiness going into the > project's repository; he is talking is about a chance to audit whatever > comes from the project's repository that *could* potentially contain some > nastiness before it causes harm to your working environment. In other > words, not *having* to trust what is in the project's repository, but > having a way to verify. > > Read what he wrote again with that in mind, and you will understand his > point. Yes, I understand. Perhaps these automatic hooks should only be applicable for "outgoing" changes like commit and push? That way you can review the hooks before they run but you still have a chance to prevent developer errors from getting to the server/other people (which is really all I care about, I am looking for a way to protect developers from making silly mistakes). -- 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