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.

> For several other things it makes a lot of sense to give the developer
> immediate feedback. Things like the format of the commit message (i.e.
> it must start with an issue tracker id) or compliance with a coding
> standard.

i.e. tracker ID. Compliance is simply a request. The developer must be
able to pick it up from surrounding style.

> 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.

> If those scripts were how ever written in a language that is build
> into the git program and the script are run in such a way that they
> can only interact with the files in the local git (and _nothing_
> outside of that) this would be solved.

GNU make.

> Also have a builtin scripting language also means that this would run
> on all operating systems (yes, even Windows).

kbuild tends to get complicated.

> So I propose the following new feature:
> 1) A scripting language is put inside git. Perhaps a version of python
> or ruby or go or ... (no need for a 'new' language)

make + go sounds like a good alternative.

> 2) If a project contains a folder called .githooks in the root of the
> code base then the rules/scripts that are present there are executed
> ONLY on the system doing the actual commit. These scripts are run in
> such a limited way that they can only read the files in the
> repository, they cannot do any networking/write to disk/etc and they
> can only do a limited set op actions against the current operation at
> hand (i.e. do checks, parse messages, etc).

Submodules and url.<url>.insteadOf come in handy 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.

> Like I said, this is just a proposal and I would like to know what you
> guys think.

> Best regards / Met vriendelijke groeten,

Which reminds me that we need to have GitTogethers. Thanks for this!
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to