Re: StGit hooks

> On 2007-11-28 14:14:15 +0100, Andreas Ericsson wrote:
> 
>> Karl Hasselström wrote:
>>
>>> On 2007-11-28 12:44:02 +0100, Andreas Ericsson wrote:
>>>
>>>> Karl Hasselström wrote:
>>>>
>>>>> Also, if StGit is to set up hooks automatically (commit hooks,
>>>>> pre-rebase hooks, whatever), it'd be nice to not have to worry
>>>>> about overwriting any existing hooks the user might have. But
>>>>> git currently allows only one hook script per hook, right?
>>>> Yes, but you can obviously call any number of scripts and
>>>> programs from within the hook that git executes.
>>> That doesn't help here, however, since the user and not StGit
>>> "owns" the "top-level" hook. StGit would have to rely on the user
>>> having installed a specific kind of multiplexer as a hook script
>>> (e.g. one that executes everything under .git/hooks/$hook.d/). Or
>>> it would have to install it itself, and hope that moving any
>>> existing hook to the subdirectory where the multiplexer looks for
>>> hooks doesn't break anything. Both solutions are problematic.
>> The user-defined hook can be kept in the hooks directory too. It
>> just needs to be named in such a way that git will never have a hook
>> named like that. For that reason, I think it would be easiest to
>> just agree for the git core to never call any hooks prefixed with
>> "stgit" or some such. I think the odds for it happening by chance
>> are remote, to say the least.
> 
> You've lost me. :-/
> 
> Take the pre-commit hook as an example. git will call
> ".git/hooks/pre-commit" when interesting stuff happens. Now StGit
> wants to install its pre-commit hook in an existing repository, and
> finds that there already is a file called ".git/hooks/pre-commit".
> What should it do?
> 

> It could move ".git/hooks/pre-commit" to
> ".git/hooks/pre-commit.d/user_hook", install its own hook in
> ".git/hooks/pre-commit.d/stgit_hook", and install a multiplexer at
> ".git/hooks/pre-commit". But that makes some assumptions, e.g. that
> the user's hook can handle being moved, and that the user is fine with
> this.
> 
> I don't see a good way around this other than having git mandate the
> multiplexing scheme.
>