I have some bare repos on local disk already, and developers with keys can work with them directly using ssh git urls.
I was hoping there was a way to get gitea to just adopt those bare repositories where they are, and users would then have a choice of either continuing to use their ssh urls as they have been doing, or using http urls from gitea, and pushes and pulls can be done using either mechanism.
(I don’t have root on this box so can’t have gitea binding 22 and anyway i’d rather not force people to give up their existing repo urls, just offer them an alternative).
But I’m finding little documentation from either gitea or gogs for this use case. I guess there is “New Repository” or “New Migration” (with or without mirror checked). But I’m not sure any of those match what I’m trying to do, nor whether what I’m trying to do is even possible - maybe gitea has hidden state somewhere in its db and can’t work with changes being applies directly to its repos.
Yes, on push, both through SSH and HTTP, there is some state that is modified outside of the actual repository, which is actually in the git hooks. You should:
- Make a backup of your repos (just in case!)
- Have the repository organized in a format similar to that of Gitea (
username/repo.git in which there are the bare files)
- Create the repositories from the web UI, under the usernames you have (they should git init --bare the repos, but not touch their contents)
- From the admin page (avatar -> admin panel), run the
Resync pre-receive, update and post-receive hooks of all repositories. task.
Where did this get to?
This is same setup as me, almost.
The idea is bind mount the real git repo in both places, the gitea location (in a LXC container) and the original location. Put in the gitea hooks, but have a bash script at /home/git/gitea that just prints out that this is a legacy location. But this means tag changes don’t show up in the gitea interface.
I looked at using /home/git/gitea to pass through the hook events, but there is quite a few environment variable to change and pass through and it seamed increasingly hacky.
Be nice if the /home/git/gitea bash script could trigger some gitea events so it was fine pushing via either method.
There is now functionality to adopt bare repositories, but unfortunately there isn’t much support for tampering with the repositories manually like that.
In order for Gitea to be notified of some of those things, it needs to be able to use those hooks.
I’ll try a little longer with my gitea proxy script then. I’ll share it if it works well enough of course.
Here’s what I did, in case anyone else needs it. Seams to be working well enough. Just working out how the new world order looks more broadly now.