On 09/10/2013 02:18 AM, 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.
>
> 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.
>
> 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'.
>
> 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.
>
> Also have a builtin scripting language also means that this would run
> on all operating systems (yes, even Windows).
>
> 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)
>
> 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).
>
> 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.).
>
> Like I said, this is just a proposal and I would like to know what you
> guys think.
I am not in favour of any idea like this. It will end in some sort of
compromise (in both sense of the word!)
It has to be voluntary, but we can make it easier. I suggest something
like this:
- some special directory can have normal hook files, but it's just a
place holder.
- each hook code file comes with some meta data at the top, say
githook name, hook name, version, remote-name. I'll use these
examples:
pre-commit crlf-check 1.1 origin
- on a clone/pull, if there is a change to any of these code files
when compared to the previous HEAD, and if the program is running
interactively, then you can ask and setup these hooks.
The purpose of the remote name in the stored metadata is that we
don't want to bother updating when we pull from some other repo,
like when merging a feature branch.
The purpose of the version number is so you can do some intelligent
things, even silently upgrade under certain conditions.
All we're doing is making things easier compared to what you can already
do even now (which is completely manual and instructions based).
I don't think anything more intrusive or forced is wise.
And people who say it is OK, I'm going to seriously wonder if you work
for the NSA (directly or indirectly). Sadly, that is not meant to be a
joke question; such is life now.
--
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
