Well you can tell them to please enable hooks in the PR guidelines, but you cannot really police what they do or don't run on their own machines.

▲

jayd16 4 hours ago | parent [-]

This is very much not a serious solution. Look at the case of LFS.

LFS needs an install step and it needed to be brought into git itself to cut through all of the problems. Manually managing hooks is not sufficient.

No amount of "please don't fuck it up" in the readme is going to save you.

Even CI checks for what should and shouldn't look like an lfs stub is non-trivial. I don't think such a thing even exists today.

▲

lou1306 4 hours ago | parent [-]

The alternative is have hooks _forcibly_ run on people's machines, which is fantastic as an attack vector and CVE generator but probably not a good choice in other respects.

	▲	jayd16 4 hours ago \| parent [-]
		No there are a million miles in-between no support/Don't use it and arbitrary code execution. Signed git plugins and manifest or a canonical way to define hooks in repo that most tools can interface with and allow the user to automatically set up but asks to do so or really so much more. I don't know why people get fixated on this as if 99.999% of what git pulls down isn't code you expect to run and there are systems in place to protect that.