You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Gitea relies on Git hooks to do several actions. Currently, the Git hooks are stored inside the repo in the Git style. In my eyes this has two significant downsides:
they take up unnecessary storage (at Codeberg, we have 2.4GB Git hooks on the disk), worsened by the fact that creating a repo creates a repo from the Git template which has some hooks by itself
if the hooks change, they need to be synchronized for all repos, a process that is linear, but still sounds like a waste of resources
Is there a reason not to store the hooks in a central place? e.g. in /data/git/hooks (or when compared to the Gitea binary, in ../hooks)?
There is the Git config core.hooksPath, which could be set in a config file or specified by Gitea for each call to the Git binary, to call the hooks in a central place. They would only need to be installed once and updated there.
I tested this on codeberg-test.org (you can also find some fancy MOTD there now), and it seems to work, although I don't know about go-git (we are using plain / native Git).
Further, Gitea could prevent Git from using the hooks by providing an own repo template, to reduce storage size.
Since the Git hooks are always executed inside the repo (no matter where they are stored), it would be easy to support placing custom Git hooks inside the repo hooks folder, by just executing them as done now.
Screenshots
No response
The text was updated successfully, but these errors were encountered:
I'm not a Gitea developer but a user. The problem with the central approach is that the git hooks would apply to all organizations/repositories. When the Gitea server is used by many teams with different requirements, then a central config would not work for all.
I am in a situation like this. Git hooks for my team would be a total drama for other teams and vice versa.
This would probably work only if custom git hooks are disabled in gitea and only gitea hooks are needed. But there is risk that this breaks if user changes that setting, so this is kind a tricky :)
@seag-rvc I think you misunderstand the idea. I'm talking about the Gitea Git hooks, which are used by Gitea to trigger certain Gitea-events on pushes etc, so they are identical for all repositories. I'm not talking about changing anything about the per-repo Git hooks. While they are obviously not allowed on Codeberg.org, it's not a problem to support them.
Since the Git hooks are always executed inside the repo (no matter where they are stored), it would be easy to support placing custom Git hooks inside the repo hooks folder, by just executing them as done now.
You can still add Git hooks inside the repo hook folders, that's not a problem. You just have to make sure the Gitea-central Git hooks fire them.
Feature Description
Gitea relies on Git hooks to do several actions. Currently, the Git hooks are stored inside the repo in the Git style. In my eyes this has two significant downsides:
Is there a reason not to store the hooks in a central place? e.g. in /data/git/hooks (or when compared to the Gitea binary, in ../hooks)?
There is the Git config core.hooksPath, which could be set in a config file or specified by Gitea for each call to the Git binary, to call the hooks in a central place. They would only need to be installed once and updated there.
I tested this on codeberg-test.org (you can also find some fancy MOTD there now), and it seems to work, although I don't know about go-git (we are using plain / native Git).
Further, Gitea could prevent Git from using the hooks by providing an own repo template, to reduce storage size.
Since the Git hooks are always executed inside the repo (no matter where they are stored), it would be easy to support placing custom Git hooks inside the repo hooks folder, by just executing them as done now.
Screenshots
No response
The text was updated successfully, but these errors were encountered: