On Tue, Sep 10, 2013 at 12:18 AM, Ramkumar Ramachandra
> 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.
>> 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
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!
Best regards / Met vriendelijke groeten,
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