Releases don't migrate from Github #613

New Issue

GiteaMirror · 2025-11-02T03:29:56-06:00

GiteaMirror commented

2025-11-02 03:29:56 -06:00

Originally created by @Rory-Anderson on GitHub (Apr 5, 2017).

Gitea version (or commit ref): 1.1
Git version: 2.9.3
Operating system: Ubuntu LTS
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant
Log gist:

Description

As the title says, when migrating a repository over from Github, it doesn't take any of the information, like title and release notes. It also leaves the attachments. I know that github allows other file types as attachments (I don't know all the types but I use .sql files a fair amount), would this mess it up?

Screenshots

Originally created by @Rory-Anderson on GitHub (Apr 5, 2017). - Gitea version (or commit ref): 1.1 - Git version: 2.9.3 - Operating system: Ubuntu LTS - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [x] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description As the title says, when migrating a repository over from Github, it doesn't take any of the information, like title and release notes. It also leaves the attachments. I know that github allows other file types as attachments (I don't know all the types but I use .sql files a fair amount), would this mess it up? ## Screenshots ![chrome_2017-04-05_07-32-18](https://cloud.githubusercontent.com/assets/24892057/24692654/054142de-19d2-11e7-8fab-123500bfb020.png)

GiteaMirror added the type/feature label 2025-11-02 03:29:56 -06:00

GiteaMirror closed this issue

2025-11-02 03:29:57 -06:00

GiteaMirror commented

2025-11-02 03:29:57 -06:00

@bkcsoft commented on GitHub (Apr 18, 2017):

Releases on GitHub isn't tied to the git-repo itself, migrating them would require talking to GitHubs API, which we purposefully don't do. Adding support to do so would lead to people asking about (or sending PRs for) supporting other providers, and there are so many different providers that it would end up as code-bloat. And the fact that there's no way to test this migrations without calling out to all those providers, meaning we'd introduce more untested code.

If you want proof of my claims, have a look at GitLabs migration-code. While nicely done, it is still in my opinion somewhat of a beast 😅 (Side-note: I did most of the Gitea-migrator for GitLab)

@bkcsoft commented on GitHub (Apr 18, 2017): Releases on GitHub isn't tied to the git-repo itself, migrating them would require talking to GitHubs API, which we purposefully don't do. Adding support to do so would lead to people asking about (or sending PRs for) supporting other providers, and there are so many different providers that it would end up as code-bloat. And the fact that there's no way to test this migrations without calling out to all those providers, meaning we'd introduce _more_ untested code. If you want proof of my claims, have a look at GitLabs migration-code. While nicely done, it is still in my opinion somewhat of a beast 😅 (Side-note: I did most of the Gitea-migrator for GitLab)

GiteaMirror commented

2025-11-02 03:29:57 -06:00

@ulm0 commented on GitHub (Apr 18, 2017):

@bkcsoft any plans on being able to add/edit releases notes and stuff?

@ulm0 commented on GitHub (Apr 18, 2017): @bkcsoft any plans on being able to add/edit releases notes and stuff?

GiteaMirror commented

2025-11-02 03:29:57 -06:00

@bkcsoft commented on GitHub (Apr 18, 2017):

One should be able to do that already, Releases are not hard-bound to a Tag AFAIK

@bkcsoft commented on GitHub (Apr 18, 2017): One should be able to do that already, Releases are not hard-bound to a Tag AFAIK

GiteaMirror commented

2025-11-02 03:29:57 -06:00

@h-2 commented on GitHub (Jun 26, 2017):

Releases on GitHub isn't tied to the git-repo itself, migrating them would require talking to GitHubs API, which we purposefully don't do.

It would be super cool if this were to change in the future ❤️

Adding support to do so would lead to people asking about (or sending PRs for) supporting other providers, and there are so many different providers that it would end up as code-bloat.

Just because you do A, doesn't mean you have to do B; there is no reason to treat mult-million-user-base platforms the same as obscure niche-products. And GitHub is the de-facto standard, I mean you are hosting your own code on GitHub instead of an instance of your own code 😉
I think it would really help adoption to make inter-operability with / conversion from GitHub as easy as possible.

@h-2 commented on GitHub (Jun 26, 2017): > Releases on GitHub isn't tied to the git-repo itself, migrating them would require talking to GitHubs API, which we purposefully don't do. It would be super cool if this were to change in the future ❤️ > Adding support to do so would lead to people asking about (or sending PRs for) supporting other providers, and there are so many different providers that it would end up as code-bloat. Just because you do A, doesn't mean you have to do B; there is no reason to treat mult-million-user-base platforms the same as obscure niche-products. And GitHub is the de-facto standard, I mean you are hosting your own code on GitHub instead of an instance of your own code 😉 I think it would really help adoption to make inter-operability with / conversion from GitHub as easy as possible.

GiteaMirror commented

2025-11-02 03:29:58 -06:00

@bkcsoft commented on GitHub (Jun 26, 2017):

@h-2

It would be super cool if this were to change in the future ❤️

Most likely will not 😉

I mean you are hosting your own code on GitHub instead of an instance of your own code

We're only doing that because Gitea is currently missing a few key features (like proper CI integration and code reviews). End goal is self-hosting.

I think it would really help adoption to make inter-operability with / conversion from GitHub as easy as possible.

While I agree with that, I don't agree that this should be part of Gitea itself.

Reasons: (almost exact copy of https://github.com/go-gitea/gitea/issues/1876#issuecomment-308588206)

Less code in Gitea makes for less bugs.
This is a "niche" thing that most users don't need or ever use.
Sure, users migrate between services, but they usually only do it once (at least from platform X to platform Y)
If it exists for platform X, people will request it for platform Y. Just saying "that platform is not big enough to be considered" is not gonna cut it, hence the feature itself is cut 🙂 Also consider what happens when someone suddenly change their API (like GitLab did in 9.0 going from v3 to v4, though still maintaining v3 for a bit longer), then Gitea would have to be updated, and this would have to be backported since not everyone wants to upgrade their instance (with the downtime and bugs that comes with that). Having this as a separate specific tool would not require users to upgrade, or maintainers to backport, but simply install a separate tool that they can throw away once they're done with it.

@bkcsoft commented on GitHub (Jun 26, 2017): @h-2 > It would be super cool if this were to change in the future ❤️ Most likely will not 😉 > I mean you are hosting your own code on GitHub instead of an instance of your own code We're only doing that because Gitea is currently missing a few key features (like proper CI integration and code reviews). End goal is self-hosting. > I think it would really help adoption to make inter-operability with / conversion from GitHub as easy as possible. While I agree with that, I don't agree that this should be part of Gitea itself. Reasons: (almost exact copy of https://github.com/go-gitea/gitea/issues/1876#issuecomment-308588206) 1. Less code in Gitea makes for less bugs. 2. This is a "niche" thing that most users don't need or ever use. Sure, users migrate between services, but they usually only do it once (at least from platform X to platform Y) 3. If it exists for platform X, people _will_ request it for platform Y. Just saying "that platform is not big enough to be considered" is not gonna cut it, hence the feature itself is cut 🙂 Also consider what happens when someone suddenly change their API (like GitLab did in 9.0 going from v3 to v4, though still maintaining v3 for a bit longer), then Gitea would have to be updated, and this would have to be backported since not everyone wants to upgrade their instance (with the downtime and bugs that comes with that). Having this as a separate specific tool would not require users to upgrade, or maintainers to backport, but simply install a separate tool that they can throw away once they're done with it.

GiteaMirror commented

2025-11-02 03:29:58 -06:00

@lafriks commented on GitHub (Jun 26, 2017):

I completely agree with @bkcsoft that there should be created tool to do migrations from different platforms to gitea

@lafriks commented on GitHub (Jun 26, 2017): I completely agree with @bkcsoft that there should be created tool to do migrations from different platforms to gitea

GiteaMirror commented

2025-11-02 03:29:58 -06:00

@bkcsoft commented on GitHub (Jun 26, 2017):

@lafriks If written properly, it would be cross direction, so Gitea <=> GitHub <=> GitLab <=> Gitea, etc...

@bkcsoft commented on GitHub (Jun 26, 2017): @lafriks If written properly, it would be cross direction, so Gitea <=> GitHub <=> GitLab <=> Gitea, etc...

GiteaMirror commented

2025-11-02 03:29:58 -06:00

@Governa commented on GitHub (Aug 24, 2017):

Maybe there could be an API/plugin system to allow for easy migration of every (supported) feature. Maybe only documenting how to create a custom script is enough. Then other people could do it as separate projects. This solves the problem of code bloat.

I use Gitolite/Redmine at work and would love to migrate then both to Gitea, but having to understand Gitea database, then Redmine database and then creating/testing a script to migrate everything is a bit too much.

@Governa commented on GitHub (Aug 24, 2017): Maybe there could be an API/plugin system to allow for easy migration of every (supported) feature. Maybe only documenting how to create a custom script is enough. Then other people could do it as separate projects. This solves the problem of code bloat. I use Gitolite/Redmine at work and would love to migrate then both to Gitea, but having to understand Gitea database, then Redmine database and then creating/testing a script to migrate everything is a bit too much.

GiteaMirror commented

2025-11-02 03:29:58 -06:00

@ghost commented on GitHub (Jul 31, 2018):

Given tags come across just fine I'm guessing the bane of this issue is people losing release notes which they stored in GitHub releases as opposed to a ChangeLog. To generate a changelog file from git history take a look at https://www.npmjs.com/package/conventional-changelog-cli

@ghost commented on GitHub (Jul 31, 2018): Given tags come across just fine I'm guessing the bane of this issue is people losing release notes which they stored in GitHub releases as opposed to a ChangeLog. To generate a changelog file from git history take a look at https://www.npmjs.com/package/conventional-changelog-cli

GiteaMirror commented

2025-11-02 03:29:59 -06:00

@jonasfranz commented on GitHub (Jul 31, 2018):

Maybe can we add support for that to the gitea GitHub migrator

@jonasfranz commented on GitHub (Jul 31, 2018): Maybe can we add support for that to the gitea GitHub migrator

GiteaMirror commented

2025-11-02 03:29:59 -06:00

@techknowlogick commented on GitHub (Sep 9, 2018):

Closing this in favour of external tool.

@techknowlogick commented on GitHub (Sep 9, 2018): Closing this in favour of external tool.

GiteaMirror referenced this issue

2025-11-02 07:38:32 -06:00