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

[Lance Edgar]

FWIW this is now enough to satisfy my own use case.


On 1/11/21 5:10 PM, Mads Kiilerich wrote:
> On 1/11/21 10:16 PM, Lance Edgar wrote:
>> On 1/11/21 7:53 AM, Mads Kiilerich wrote:
>>
>> The only thing I spotted in the above PR was this bit where you would 
>> remove any existing pre-receive hook.  Seems to me that the admin may 
>> well need to install pre-receive for their own needs and you should 
>> never delete it even when "force overwrite" is requested?  Or maybe I 
>> read it wrong.
>>
>> https://kallithea-scm.org/repos/kallithea-incoming/changeset/e7acbdb8fd8ce7d520ce216b5baeb42a72dc7fdd#kallitheamodelscmpy_n717 
>>
>
>
> Right, thanks. I propose 
> https://kallithea-scm.org/repos/kallithea-incoming/changeset/9522b915c913#kallitheamodelscmpy_n674 
> instead.


Thanks, that looks safer.


>>> Finally, with these things out of the way, the core problem of 
>>> custom/multiple Git hooks is more clear.
>>>
>>> The way Kallithea use Git, I see no alternative to Kallithea 
>>> installing the post-receive hook to be able to detect what has been 
>>> pushed. (But it is possible we could come of with another scheme, 
>>> and thus completely avoid this problem?)
>>
>>
>> Agreed, I see no reason not to use git hooks for Kallithea's own needs.
>
>
> Well ... there is at least one good reason: it evidently conflicts 
> with admins who want other kinds of hooks ;-)


Ha, touché.  I just have no idea how Kallithea could do what it needed, 
without hooks.  Maybe I lack imagination but it seems like hooks are 
ideal for it.


>> All that does make sense.  However I would like to propose yet 
>> another way of looking at it.
>>
>> We have been discussing "multiple post-receive hooks" but in reality 
>> there need only ever be 2:  Kallithea's own "internal" hook script 
>> (in use today), and "some other" script as defined by admin.
>>
>> Git after all will only support one script out of the box, so any 
>> admin who needs "multiple" things to happen in a hook, normally must 
>> write one script which contains several steps.  So then "all extra" 
>> steps needed beyond Kallithea could be represented as a single 
>> script.  If the admin's needs are complex then maybe that script for 
>> them must have the "meaningful handling of stdin" etc. which you 
>> mentioned. (Perhaps with auto-discovery, like example at 
>> https://serverfault.com/a/909154 .)  But there would be no true need 
>> for the "dispatcher" to have those smarts - it need only a) run the 
>> Kallithea hook, and then b) run the "other" hook script if present.  
>> (I guess, it *would* still need to correctly pass stdin at least.)
>
>
> I do not like to see it as at most two hooks, Kallithea's and the 
> admins. That will force admins to solve the same problem as we have 
> to: Figure out a way to dispatch to multiple hooks. That is an 
> artificial and egoistic way to reduce a generic N problem to a "me vs 
> everybody else" 2 problem.


Understandable.  I don't personally have an issue with "at most two 
hooks" simply because that is no worse than "at most one hook" which is 
default Git behavior.  If Kallithea did not need to install a hook at 
all, then it would effectively "stay out of the way" and admin would 
manage the hooks using their "normal" approach.  Since it does need a 
post-receive hook, it has the added burden of defining where/how admin 
can still configure their own "custom" post-receive hook.

That's just me repeating the obvious maybe.


>> I agree that a smarter dispatcher might be a nice gift to the Git 
>> world, beyond Kallithea.  But I think it is not strictly necessary here.
>>
>> I was curious about what GitLab did for this.  IIUC their Server 
>> Hooks doc 
>> (https://docs.gitlab.com/ee/administration/server_hooks.html) 
>> basically reduces the problem in the same way.  They allow the admin 
>> to create a `custom_hooks` folder in the repo, and in it they can 
>> place a (single!) `post-receive` script for example. Presumably the 
>> "true" hook script from Git's perspective, is the one provided by 
>> GitLab itself, but as an optional last step it can fire off whatever 
>> is in `custom_hooks/post-receive` if present.
>>
>> So ultimately I agree that "Kallithea having its own custom way of 
>> allowing admins to install hooks" is not 100% ideal, but that "they 
>> should do it in a standard way" seems to me still possible and pretty 
>> low-hanging fruit, without adding in a 3rd party dispatcher.  
>> (Although by "standard" I am only referring to the "Kallithea 
>> standard way" here.)  We need only define/document a single custom 
>> hook script/path which the admin must define, *should* they even need 
>> to bother.
>>
>> If some day Git is given native multi-hook support then obviously 
>> should revisit.  But I suspect their approach will never change since 
>> end user can always make a wrapper script, e.g. also 
>> https://stackoverflow.com/a/30104427
>
>
> So sad that the Git world seems to rely on hacks instead of solutions :-(
>
> So how about something like 
> https://kallithea-scm.org/repos/kallithea-incoming/changeset/027e5f06c7e7 
> ?


That seems to do what I want, so thanks again.  I look forward to next 
release!

I could imagine a world where Kallithea exposed all available git hooks 
for maintenance within the UI, and perhaps had a smart dispatcher(s) to 
allow multiple hooks of each type.  Who knows maybe that even would add 
to the attraction of Kallithea over other options, e.g. GitLab.  I don't 
think it would have swayed my own decision, which had more to do with 
true software freedom. And if the dispatcher needed to be a 3rd party 
project then that may just complicate things?  Anyway just some more of 
my 2c.

Lance