[PATCH] git: move non-kallithea hooks and execute other hooks

[Mads Kiilerich]

On 10/20/20 5:19 PM, Tim Ooms wrote:
> # HG changeset patch
> # User Tim Ooms <tatankat at users.noreply.github.com>
> # Date 1603201903 -7200
> #      Tue Oct 20 15:51:43 2020 +0200
> # Node ID 672e57b165d0c1774b692b5706a174bf98f42e4c
> # Parent  b9b53e25a08d3714c54d82641b419e6d01820e12
> git: move non-kallithea hooks and execute other hooks


Thanks for working on this.

It might have rough edges to bypass Kallithea when accessing 
Kallithea-managed repos. It is perhaps better to go with the assumption 
that Kallithea fully owns the repositories it manage.

Can you say more about your use case? What other hooks are installed? 
What precautions do they use to avoid clobbering the Kallithea hooks?

It must be a general challenge with Git to fit multiple hooks into the 
single hook slot. Is there any prior art for solving / working around 
that problem?

It would be nice if there was a "standard" dispatcher (perhaps a simple 
shell script) that could be installed in The Hook Location - something 
that picked up multiple hook files. Instead of having our hook call 
others, it would perhaps be better to install a generic-ish hook and let 
it dispatch to both our hook and the existing one.

The solution proposed here also touch upon lessons learned from general 
/etc/xxx.rc/ configuration systems: People will often want to rename 
configuration files to something like '.bu' or '.old' or '.disabled'. It 
is thus a very good idea to only match on one file extension - and 
perhaps also a prefix. The "real" hooks do not have any extension, but 
the globbed ones could perhaps match 'pre-receive.*.hook'? Also, we 
should check that they are executable for the current user before trying 
to run them.

For the chmod changes, I think we only should care about the hooks we 
install. If the existing hook isn't executable, git will ignore it and 
we should do the same - not try to clean things up we don't know about. 
We just wrote our own hook file, so we know it isn't a symlink, and 0755 
should be fine? Ideally, we should probably use umask and set X bit ... 
but I doubt that ever will make any difference.

/Mads