-
Notifications
You must be signed in to change notification settings - Fork 19
Description
I have the following szenario I was thinking about.
When using Gitea, it will create repos for you somewhere on the server. Assume there is githooks installed.
Because Gitea is not aware of githooks, it just forcefully overwrites into the bare repo.git/hooks directory some hooks it need to run. Thats kind of bad if githooks init.templateDir is in place...
I actually want for all repos on the server to be using githooks.
Thats why I installed githooks with core.hooksPath
- I copied the relvant Gitea hooks (which get installed whenever a new repo is created) to the core.hooksPath folder first,
- then installed githooks over it (which will replace them)
core.hooksPathis now running for every repo, and also executing the "execute_old_hook_if_available" from Gitea
Gitea can now create new repos and every thing is fine since the local repo.git/hooks gets ignored anyway and these hooks are now executed since I copied them in the first place.
I was wondering: Could we make the base-template such that when githooks.useCoreHooksPath is true we can
additionally (maybe as a opt-in) also execute the hooks in GIT_DIR/hooks.
In that way I dont need to clumsily copy the Gitea hooks to the core.hooksPath ( I even dont know if there are not somewhen more hooks or different ones and so forth...).
So the procedure whould be:
if are_githooks_disabled; then
execute_lfs_hook_if_appropriate "$@" || return 1
execute_old_hook_if_available "$@" || return 1
return
fi
execute_lfs_hook_if_appropriate "$@" || return 1
# NEW -------------
if githooks.useCoreHooksPath is true and option-setting is enabled; then
execute_all_hooks_in "$GIT_DIR/hooks"
fi
# NEW -------------
# Execute old replaced hooks next to where the base-template-wrapper.sh
execute_old_hook_if_available "$@" || return 1
# Global setup
execute_global_shared_hooks "$@" || return 1
# Repository local setups
execute_local_shared_hooks "$@" || return 1
execute_all_hooks_in "$(pwd)/.githooks" "$@" || return 1What do you think?
I am really not sure if this is really good to support... hm... It just solves my problem but its another setup which makes things to understand a bit harder...