how to migrate repositories from one gitea-instance to another #139

n0542344 commented 2021年06月10日 17:45:12 +02:00

This pull/merge request contains some documentation on how to migrate a repo you own to another gitea-instance. The example I used is locally hosted gitea instance on an Arch Linux machine (and I also included install infos for that).

Before merging this into main/master please consider: although it works for me this should be tested by someone else on their system (I only tried this on a single machine running Parabola GNU/Linux).

In addition: please consider that I tried to show the easiest way to install gitea but not the 'best' one, therefore I would not recommend this gitea installation for multi-user systems or in cases where other people are accessing this gitea instance.

I'd appreciate any feedback!

Best wishes, Alex

This pull/merge request contains some documentation on how to migrate a repo you own to another `gitea`-instance. The example I used is locally hosted `gitea` instance on an `Arch Linux` machine (and I also included install infos for that). Before merging this into main/master please consider: although it works for me this should be tested by someone else on their system (I only tried this on a single machine running [`Parabola GNU/Linux`](https://www.parabola.nu/)). In addition: please consider that I tried to show the easiest way to install `gitea` but not the 'best' one, therefore I would not recommend this `gitea` installation for multi-user systems or in cases where other people are accessing this `gitea` instance. I'd appreciate any feedback! Best wishes, Alex

fnetX commented 2021年06月10日 18:42:00 +02:00

Hey there and thank you for this pull.

I think the migration documentation should not be too specific to the use case of moving away from Codeberg, especially for the Codeberg Documentation. I'm fine with having a general Gitea-to-Gitea migration guide that is generic and works with any Gitea instance. Mentioning that this works for Gitea → Codeberg, Codeberg → Gitea and of course Gitea → Gitea.
Essentially make sure to cover #35.

I also don't think that installation guides should be in the Codeberg documentation, as we won't be able to maintain this and make sure it's up to date, secure and working. If you think that the Gitea docs can be improved, please send patches there, but I don't think we should cover this on Codeberg.

Also have a look at #135. I'm fine if you link to somewhere for running your own Gitea instance in the migration guide, too. Also, in Codeberg/Community#463, we are seeing a roadmap of enabling Codeberg / Gitea login to a third-party service. I'd rather extend in this direction with a new Pull Request and explain users how they can have their self-hosted Gitea, but still allow sign-in via Codeberg and / or other Gitea instances (thinking of disroot etc).

Just my early thoughts so far, if you think we should review it as-is, just remove the WIP prefix and I'll have a closer look at the content 😉

Hey there and thank you for this pull. I think the migration documentation should not be too specific to the use case of moving away from Codeberg, especially for the Codeberg Documentation. I'm fine with having a general Gitea-to-Gitea migration guide that is generic and works with any Gitea instance. Mentioning that this works for Gitea → Codeberg, Codeberg → Gitea and of course Gitea → Gitea. Essentially make sure to cover #35. I also don't think that installation guides should be in the Codeberg documentation, as we won't be able to maintain this and make sure it's up to date, secure and working. If you think that the Gitea docs can be improved, please send patches there, but I don't think we should cover this on Codeberg. Also have a look at #135. I'm fine if you link to somewhere for running your own Gitea instance in the migration guide, too. Also, in Codeberg/Community#463, we are seeing a roadmap of enabling Codeberg / Gitea login to a third-party service. I'd rather extend in this direction with a new Pull Request and explain users how they can have their self-hosted Gitea, but still allow sign-in via Codeberg and / or other Gitea instances (thinking of disroot etc). Just my early thoughts so far, if you think we should review it as-is, just remove the WIP prefix and I'll have a closer look at the content 😉

n0542344 commented 2021年06月10日 20:43:27 +02:00

Wow, that was a fast reply - thanks for that!

I think the migration documentation should not be too specific to the use case of moving away from Codeberg, especially for the Codeberg Documentation.

If that's the official stand of Codeberg I'll accept that. But I think that this is an essential feature and one of the reasons why I'm currently planning to move my repos away from https://gitlab.com and to https://codeberg.org is the fact that I assume that the migration process is a lot more straight forward compared to https://git{hu,la}b.com (and therefore I don't need to be afraid of vendor lock-ins).

I'm fine with having a general Gitea-to-Gitea migration guide that is generic and works with any Gitea instance. Mentioning that this works for Gitea → Codeberg, Codeberg → Gitea and of course Gitea → Gitea.

OK, that sounds fine, I'll reword that section to tone it down.

Essentially make sure to cover #35.

Thanks for the pointer!

I also don't think that installation guides should be in the Codeberg documentation, as we won't be able to maintain this and make sure it's up to date, secure and working. If you think that the Gitea docs can be improved, please send patches there, but I don't think we should cover this on Codeberg.

Good point. I'll change it to be more general.

Also have a look at #135. I'm fine if you link to somewhere for running your own Gitea instance in the migration guide, too.

OK, I will.

Also, in Codeberg/Community#463, we are seeing a roadmap of enabling Codeberg / Gitea login to a third-party service. I'd rather extend in this direction with a new Pull Request and explain users how they can have their self-hosted Gitea, but still allow sign-in via Codeberg and / or other Gitea instances (thinking of disroot etc).

Interesting... I'll need to have a closer look at that.

I'll try to fix the issues tomorrow and remove the WIP then.

Wow, that was a fast reply - thanks for that! > I think the migration documentation should not be too specific to the use case of moving away from Codeberg, especially for the Codeberg Documentation. If that's the official stand of Codeberg I'll accept that. But I think that this is an essential feature and one of the reasons why I'm currently planning to move my repos away from https://gitlab.com and to https://codeberg.org is the fact that I assume that the migration process is a lot more straight forward compared to https://git{hu,la}b.com (and therefore I don't need to be afraid of vendor lock-ins). > I'm fine with having a general Gitea-to-Gitea migration guide that is generic and works with any Gitea instance. Mentioning that this works for Gitea → Codeberg, Codeberg → Gitea and of course Gitea → Gitea. OK, that sounds fine, I'll reword that section to tone it down. > Essentially make sure to cover #35. Thanks for the pointer! > I also don't think that installation guides should be in the Codeberg documentation, as we won't be able to maintain this and make sure it's up to date, secure and working. If you think that the Gitea docs can be improved, please send patches there, but I don't think we should cover this on Codeberg. Good point. I'll change it to be more general. > Also have a look at #135. I'm fine if you link to somewhere for running your own Gitea instance in the migration guide, too. OK, I will. > Also, in Codeberg/Community#463, we are seeing a roadmap of enabling Codeberg / Gitea login to a third-party service. I'd rather extend in this direction with a new Pull Request and explain users how they can have their self-hosted Gitea, but still allow sign-in via Codeberg and / or other Gitea instances (thinking of disroot etc). Interesting... I'll need to have a closer look at that. I'll try to fix the issues tomorrow and remove the WIP then.

fnetX commented 2021年06月10日 21:37:40 +02:00

Thank you very much for picking this up, no need to hurry at all!

If that's the official stand of Codeberg I'll accept that.

We're community-maintained, you can get this into the docs if one (or maybe in a controversial situation two) people approve. I'd approve this, too, just wanted to point out that this sounds a bit off if we only cover this specific use-case (although your explanation makes sense to me).

Looking forward to seeing this deployed.

Thank you very much for picking this up, no need to hurry at all! > If that's the official stand of Codeberg I'll accept that. We're community-maintained, you can get this into the docs if one (or maybe in a controversial situation two) people approve. I'd approve this, too, just wanted to point out that this sounds a bit off if we only cover this specific use-case (although your explanation makes sense to me). Looking forward to seeing this deployed.

n0542344 commented 2021年06月11日 12:31:33 +02:00

I updated the docs as discussed (although I'm not sure if I fixed all the points from our discussion...)

I updated the docs as discussed (although I'm not sure if I fixed all the points from our discussion...)

n0542344 commented 2021年06月11日 14:41:11 +02:00

Thanks for the feedback - I updated the points you mentioned accordingly.

Thanks for the feedback - I updated the points you mentioned accordingly.

fnetX commented 2021年06月12日 12:55:32 +02:00

Heads up: I just shortened the article name to better reflect the article content + simply make it shorter (sharing etc).

Heads up: I just shortened the article name to better reflect the article content + simply make it shorter (sharing etc).

n0542344 commented 2021年06月22日 14:37:27 +02:00

Awesome, thanks for the heads-up!

Awesome, thanks for the heads-up!