On Wed, Apr 07 2021, Junio C Hamano wrote: > 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? FWIW I've been assuming that this is wanted for BigCorp people who have devs using vanilla OS's / XCode etc. Having managed laptops with a managed /etc/gitconfig certainly makes some things easier... > Wouldn't it be just a matter of the BigCorp installing > /etc/gitconfig on their BigCorpLinux installations? Whether you're at BigCorp or not you've got the problem with such a /etc/gitconfig that it applies to all repos, but someone at BigCorp might clone both a BigCorp repo (wants custom config, hooks etc.), and also some random node.js github.com project (should have no such custom config). Having a .gitconfig or otherwise making the repo suggest/control the config/hooks is an elegant way around that issue. You otherwise need to do something like have config includes apply a rule to ~/work/, and then hope your users follow your suggestion to clone repos in the ~/work/ folder. I think extending config includes to e.g. operate on a glob of the remote URI was suggested at some point, which would make use-cases like that easier than they are now, and would be a less invasive change than what's being discussed here. But right now we don't have that, so we have a gap there...
