additional hooks (ie commit-msg)

[betaboon]

Hello there,

First off:
I'm glad i found autohooks as it addresses the downsides i see with pre-commit when using it with python (namely configuration via pyproject.toml and being able to managing dependencies with poetry)

Now to my question:
I'm trying to integrate commitizen which is normally ran in the commit-msg-hook.
After digging through autohooks-code it seems like it is only managing the pre-commit-hook.

It would be great if we could manage all the hooks.

(I'll call the individual hooks in .git/hooks/ stages from now on)

The requirements i see:

• allow managing of all stages
• have activate register a script for all stages by default
• add config-option to define which stages to register
• add argument to activate to define which stages to register (aka "i only want pre-commit and commit-msg")
• allow plugins to define which stage they run in by default
• allow the user to override which stage a plugin runs in

I would be glad to get some feedback on this idea.

thanks in advance

[bjoernricks]

Hi, thanks for getting in touch!

allow managing of all stages

autohooks was always designed with supporting all stages in mind. We just didn't needed other stages beside pre-commit yet. Thus I am of course open to all kind of changes in this regard.

Your items are all valid and sophisticated. Just my short thoughts about it. The configured plugins should define which stages are used by default and the user should get the hidden power to override the behavior. From reading your items it seems you have something similar in mind.

Feel free to create PRs. Please make the PRs as small as possible. If you add smaller PRs it is much more likely that we can integrate them quickly without much effort. Reviewing longer PRs that touch several areas and change behavior will take some time because this is only a side project and hasn't high priority.

[betaboon]

hey there, thanks for the reply.

I'm just looking at the code trying to figure out the best approach to get this working.

I totally agree with small PRs, but looking at the code and how the pre-commit-notion runs all through the codebase (in naming of variables, functions, classes) the proper approach seems to get that part hook-agnostic first (eg inautohooks/hooks.py renaming PreCommitHook to GitHookand so on)

but that feels hella invasive.
I'll give it a shot to get the wording right first before changing any functionality to see how big a change that would end up being.

[grahamtt]

Hey @betaboon have you made any progress on this? If not, I might take a shot at it. I don't want to duplicate work, though.

[betaboon]

Nope, ended up doing got due to lack of feedback in this issue