I started importing a github repo 3H ago, and the import is still running, no idea how much more time it will take.
I'd bet the thing is stuck... and would like to know if it really is, and if yes, or if too much time is required, how to cancel it, so that instead I could just git push instead (I'm pretty sure it will take a lot less time).
know estimate of time remaining to complete an import, and option to cancel it #723
Imports are restricted by the API rate limits of external platforms (e.g. GitHub, GitLab). It's really hard to tell.
Improvements are hard as long as proprietary platforms enjoy you are vendor locked and don't want you to move away. Gitea is working on restoring GDPR data dumps instead, which might be a good option for the future.
Having a more verbose log of what the migration tool is actually doing might be worth a further look, though.
@fnetX is there a gitea-related issue on that? (Couldn't find one during a quick search.)
I have created a new "Find-grained personal access token" on GitHub and started a migration of a GitHub repository to Codeberg. 20+ minutes later, the token is still listed as "never used" on https://github.com/settings/tokens?type=beta
So it looks not like rate limiting on the GitHub side, but the migration getting stuck in some job queue of Codeberg.
So it looks not like rate limiting on the GitHub side, but the migration getting stuck in some job queue of Codeberg.
Keep in mind that these situations are very context-specific and change super fast. The job queue of Codeberg may play a role now, but it may not have played a role with OP's problem.
I would suggest opening a new issue for this using "Reference in a new issue" and that we open a new Gitea issue for what fnetX suggested as well. (I can't do this right now.)
I suppose that the access token is not used while cloning the Git repo itself, only for accessing the metadata like issues, releases etc.
Also note that the rate limiting is not imposed per token but per IP address, thus applies to Codeberg as a whole, and yes it sometimes does impact the Git cloning, too. (Not always, though)
Reduces accessibility and is thus a "bug" for certain user groups on Codeberg.
Something is not working the way it should. Does not concern outages.
Errors evidently caused by infrastructure malfunctions or outages
This issue involves Codeberg's downstream modifications and settings and/or Codeberg's structures.
Please join the discussion and consider contributing a PR!
No bug, but an improvement to the docs or UI description will help
This issue or pull request already exists
New feature
Involves changes to the server setups, use `bug/infrastructure` for infrastructure-related user errors.
An issue directly involving legal compliance
involving questions about the ToS, especially licencing compliance
Please consider editing your posts and remember that there is a human on the other side. We get that you are frustrated, but it's harder for us to help you this way.
Things related to Codeberg's external communication
More information is needed
This issue contains a clearly stated problem. However, it is not clear whether we have to fix anything on Codeberg's end, but we're helping them fix it and/or find the cause.
Related to Forgejo. Please also check Forgejo's issue tracker.
Migration related issues in Forgejo
Issues related to the Codeberg Pages feature
Issue is related to the Weblate instance at https://translate.codeberg.org
Woodpecker CI related issue
involves improvements to the sites security
Add a new service to the Codeberg ecosystem (instead of implementing into Gitea)
An open issue or pull request to an upstream repository to fix this issue (partially or completely) exists (i.e. Gitea, Forgejo, etc.)
Codeberg's current set of contributors are not planning to spend time on delegating this issue.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?