Albert Cui <albertqcui@xxxxxxxxx> writes: >> Here are the hard lines I draw: >> >> 1. This should not happen in "git clone" (other than maybe a message >> over stderr that hooks are available to be configured through a >> different command). >> >> 2. Hooks should not update in "git checkout" (other than a message >> that hooks have updated). >> > > To Ævar's point, maybe it would help to separate the two user bases of > project configured hooks. > (1) Employee working at BigCorp. They are cloning from a trusted > remote on company machines where the company controls what gets > installed and how Git is configured. Their motivation is to make > changes to their local clone and submit changes to a central > repository. Hmph. If the assumption is that their configuration is controlled by BigCorp when they arrive at their desk, why do you even need any change to upstream Git, especially with Emily's "configuration file tells Git what hook scripts to run" in sight? Wouldn't it be just a matter of the BigCorp installing /etc/gitconfig on their BigCorpLinux installations?
