When running “subgit install” on a Git repository created by Gitea, the Gitea generated hooks will stop functioning. This is because the Gitea hook makes the same assumption SubGit does: that the script file name is the name of the hook being invoked.
So, when subgit renames the Gitea pre-receive and post-receive hook files to user-pre-receive and user-post-receive, Gitea now believes the hook names are “user-pre-receive” and “user-post-receive”. This causes it to fail to find the user hooks in the “pre-receive.d” and “post-receive.d” directories as it’s now looking in “user-pre-receive.d” and “user-post-receive.d”.
I was able to work around this by fixing the Gitea scripts to hard code the hook name rather than base it on the file name, but I wanted to bring it up with you. Alternatively, I probably could have renamed the hook directories to “user-pre-receive.d” and “user-post-recieve.d”.
Would it be possible for SubGit to add its pre-receive and post-receive scripts to the “pre-receive.d” and “post-receive.d” folders, if detected, rather than replacing the current one for gitea installations?
SubGit indeed relies upon Git hooks to perform on-push synchronization with SVN and it is designed to use standard Git hooks thus replacing them during installation. I’m afraid for the time being, we don’t have plans to change this behaviour. For Gitea, we recommend that exact workaround you have mentioned – renaming hook directories to “user-pre-receive.d” and “user-post-recieve.d” and adding
[svn]
…
triggerSvnPostReceive = true
to the SubGit configuration so that SubGit triggers the hooks.
This actually won’t work for reasons specific to Gitea. While renaming the directories does result in the hooks firing again, Gitea will reject the hooks for security purposes.
Apparently Gitea expects certain environment variables to be present and, if not, rejects the hook. Their reasoning is that all commits must go through https or ssh for Gitea installs and any commits directly to the repository are an “unsupported configuration”.
So unless SubGit supports synchronizing to Git through https/ssh, I’ll have to live with the SVN commits not appearing in Gitea correctly.
it looks that this behaviour has been changed in latest Gitea, indeed, so this approach is not working anymore. A workaround that comes to my ,ind immediately is that the Gitea hooks can be edited to include SubGit’s hooks code; it’s not a scalable solution, of course, and it also would require some manual interaction after every subgit install, but still, should be working.
Another workaround is to not to use SubGit’s hooks – in this case SubGit will not be able to run SVN synchronization prior to apply Git changes, but the synchronization will still be working using the periodic fetch that SubGit daemon performs: the matter is that SubGit uses hooks to run synchronization and send Git changes at the time they come to the repository, but in addition to that it runs a daemon that connects to SVN periodically (once a minute by default) to fetch changes made on SVN side. So it’s possible to only rely on this periodic fetch without using the hooks – this is not a recommended approach and it can lead to conflicts what there are new changes in Git while the same reference is changed on the SVN side – but still, it will be working and keep the SVN and Git synchronized.
As for the sync through https or ssh – SubGit is not able to do that, indeed, it requires direct access to the Git filesystem; but it is possible to establish a setup with an interim SubGit server that would provide alike functionality, here is an article that describes such an approach: