git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [Proposal] Clonable scripts

From
Ramkumar Ramachandra <artagnon@gmail.com>
Date
Sep 9, 2013, 22:18 UTC
Message-ID
<CALkWK0nk1KfL7YuTKuKJecPSxmu7gXmo67i2Ezb2QY5qmdN+rA@mail.gmail.com>
In-Reply-To
<CADoiZqpec6rPOgPLPQFFfLdE+Cc4ZKtWs0Q0VSfKGm3b1Lai2g@mail.gmail.com>
Niels Basjes wrote:
Show 5 quoted lines
> 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.

Show 5 quoted lines
> 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.
Show 7 quoted lines
> 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!
Previous: Niels BasjesNext: Niels Basjes
Message 4 of 7 in “[Proposal] Clonable scripts”
  1. Niels BasjesSep 9, 2013
  2. Hilco WijbengaSep 9, 2013
  3. Niels BasjesSep 9, 2013
  4. Ramkumar RamachandraSep 9, 2013
  5. Niels BasjesSep 10, 2013
  6. Sitaram ChamartySep 10, 2013
  7. Andreas KreySep 10, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.