Hi, On Tue, Sep 10, 2013 at 12:18 AM, Ramkumar Ramachandra <artag...@gmail.com> wrote: > Niels Basjes wrote: >> As we all know the hooks ( in .git/hooks ) are not cloned along with >> the code of a project. >> Now this is a correct approach for the scripts that do stuff like >> emailing the people responsible for releases or submitting the commit >> to a CI system. > > More often than not, maintainers come with these hooks and they keep > them private.
Yes. >> Initially I wanted to propose introducing fully clonable (pre-commit) >> hook scripts. >> However I can imagine that a malicious opensource coder can create a >> github repo and try to hack the computer of a contributer via those >> scripts. So having such scripts is a 'bad idea'. > > I think it's a good idea, since the contributer can look through the scripts. What I meant to say is that having "fully functional unrestricted scripts" that are cloned is a "bad idea". Having "restricted cloned scripts" to me is a "goog idea" (or atleast, that is what I propose here). >> 3) For the regular hooks this language is also support and when >> located in the (not cloned!) .git/hooks directory they are just as >> powerful as a normal script (i.e. can control CI, send emails, etc.). > > I'm confused now; how can .git/hooks be as powerful as .githooks? The > former users should consider uploading their code on GitHub. The way I envisioned is is that the scripting language in .git/hooks is "pick any language you like" with the builtin language as a new addition. In the .githooks (which is under version control in the code base and cloned) is a the same builtin language, yet constrained in a sandbox. > Which reminds me that we need to have GitTogethers. Thanks for this! You're welcome. -- Best regards / Met vriendelijke groeten, Niels Basjes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
