Migrating Repository Folder

Install/Maintain/Configure

Akito February 12, 2025, 8:28am 1

I’m gonna make this short, because the whole story is too cumbersome to tell.

1. I migrated Gitea data, including database and Git repositories, onto a fresh Gitea instance installed via Helm on Kubernetes.
2. Everything works.
3. Changed ROOT for gitea-repositories in app.ini.
4. Yes, it is absolutely correct. I checked it 20 times and corrected some mistakes in the process. It is absolutely correct.
5. All repositories are “unadopted”, i.e. orphaned. I can successfully adopt them in the Web UI.
6. I don’t wanna adopt hundreds of repositories, each one by hand via a Web UI.

I need some curl, to automatically adopt all orphaned repositories in the gitea-repositories folder. As everything is configured correctly, they are all found fine and adoption works fine.
So, I just need a mass adoption feature.

I don’t want to use the Gitea binary. It’s a Kubernetes installation and I don’t even know, if I can run a Gitea binary side by side, while one is already running. Too much of a hassle to go into this bad approach.

Need a curl, which I can loop for mass adopting all orphaned repositories.

A great bonus would be, to stop making the repositories “updated” in the Web UI, just because I adopted them. It would be better, if they would show the last actual date, that they were touched. Adopting an untouched repository is in my view no “update” to the repository, whatsoever.

Thank you for any constructive feedback!

Akito February 14, 2025, 6:45pm 2

github.com/go-gitea/gitea

Learnings from Manual Migration of Gitea Data to Fresh Gitea Instance

opened 06:34PM - 14 Feb 25 UTC

theAkito

type/proposal

### Feature Description Migrated from Gitea ~1.18 to 1.23.3. Plain Standard Kub…ernetes Single-Node Installations. ## Tasks * For permission issues with data inside volumes, where a repository cannot be accessed, the Web UI should complain specifically about permission issues, not just say to "contact the administrator". I am the administrator... * When `gitea-repositories` is not found, then error out. Do not just show no repositories, even though the database knows better, that there *should* be repositories, but they are missing. * When `lfs` folder is not found, stop deleting all repositories from database!! Error out and tell the user, that expected LFS files are missing! * When `lfs` folder is not found, stop wiping repositories, that do not even use `lfs`, at all. Just error out on those, which actually use LFS. * Generally improve errors regarding configuration issues, whenever some folder is not found or whatever. * Support Git data exports, where, for example, you get a JSON with a list of pull-based mirrors with all Gitea related metadata. On the new instance, those mirrors can just be re-pulled from remote, rather than me copying them all over the place. * Document orphan repository adoption. * Expose REST API for adopting and managing orphan repositories. * Give more options, when adopting orphanded repositories. For example, optionally set creation date, mirror boolean, template boolean, etc. * Ideally, re-vamp adoption of orphan repositories. If orphanded repositories match ones, that are already in database, then merge the metadata of the same-named repositories with the new adopted one. For example, if I adopt `akito/myrepo` and the database already knows `akito/myrepo` at a different `gitea-repositories` folder, than optionally merge the metadata from the "old" repo to the "new" one. ## Related https://forum.gitea.com/t/migrating-repository-folder/10775 ## Additional Information Since adopting orphaned repositories is half broken in Gitea, I decided to just 1:1 migrate repositories and LFS files, so I don't have to deal with the problems associated with adoption of orphans.