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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
