Request - Change org after mirroring has processed. #163

New Issue

2026-10-05T01:45:22+02:00

adam commented

2026-10-05 01:45:22 +02:00

Hello, I continue to use this every day, love this program.

I was just wondering if it would be possible to change the owner or the organization after mirroring has happening because I need to clean up my mirrors, and I can easily do that in Gitea, but then gitea-mirror will maybe have trouble doing subsequent syncs in hindsight, if the owner is changed?

Hello, I continue to use this every day, love this program. I was just wondering if it would be possible to change the owner or the organization after mirroring has happening because I need to clean up my mirrors, and I can easily do that in Gitea, but then gitea-mirror will maybe have trouble doing subsequent syncs in hindsight, if the owner is changed?

adam closed this issue

2026-10-05 01:45:22 +02:00

adam commented

2026-10-05 01:45:23 +02:00

@Ratasan64 Thanks, glad it is useful.

Today this does not work well, and I want to be upfront about the failure mode. If you transfer a mirror to another org in Gitea, the next sync only looks at the location the app recorded and the one the strategy computes, finds neither, and fails. A retry then creates a fresh mirror at the old location, so you end up with two copies. Changing the destination in the app after mirroring does not move anything either, it only changes the label. Reconcile does match the moved repo by its source URL, but it never records the new location.

Two steps:

Make moving in Gitea just work. Reconcile will report a mirror that moved and record its new location, and a sync that cannot find the repo at the known locations will look it up by name and source URL before failing. That covers your case: clean up in Gitea, and the app follows. This is what I am doing first.
Moving from the app. Changing the destination org on a mirrored repository will transfer it through Gitea's API and record the new location. That comes after.

Until the first part lands: do the cleanup in Gitea, but do not press Retry on a repo that then fails to sync, or you get a duplicate. I will post here when it is released.

@Ratasan64 Thanks, glad it is useful. Today this does not work well, and I want to be upfront about the failure mode. If you transfer a mirror to another org in Gitea, the next sync only looks at the location the app recorded and the one the strategy computes, finds neither, and fails. A retry then creates a fresh mirror at the old location, so you end up with two copies. Changing the destination in the app after mirroring does not move anything either, it only changes the label. Reconcile does match the moved repo by its source URL, but it never records the new location. Two steps: 1. Make moving in Gitea just work. Reconcile will report a mirror that moved and record its new location, and a sync that cannot find the repo at the known locations will look it up by name and source URL before failing. That covers your case: clean up in Gitea, and the app follows. This is what I am doing first. 2. Moving from the app. Changing the destination org on a mirrored repository will transfer it through Gitea's API and record the new location. That comes after. Until the first part lands: do the cleanup in Gitea, but do not press Retry on a repo that then fails to sync, or you get a duplicate. I will post here when it is released.

adam commented

2026-10-05 01:45:24 +02:00

Released in v3.32.0.

What changed:

Editing a repository's destination now asks whether to move the mirror on Gitea too (ticked by default). For an organization there is a checkbox in the destination popover and a confirmation that lists what will move. The target org is created if it does not exist. If your token cannot create repositories under the new owner, Gitea holds the transfer until one of its owners accepts it; sync keeps working at the old place until then and follows the mirror afterwards.
Sync now finds a mirror you moved by hand in Gitea instead of failing, and Retry no longer creates a second copy. Reconcile (Configuration > Automation) lists moved mirrors and can record their new location. Copies made by an earlier Retry show up there under "not managed" so you can delete them in Gitea yourself.

Please go ahead and test it, but take a backup of everything first: data/gitea-mirror.db and your Gitea instance, or at least the repositories you are going to move. The transfer path was built from Gitea's API and unit tests, and I have not yet run it against a live Gitea, so treat it as untested until you have. The app never deletes anything on either side, and the Reconcile dialog can put the rows back in step with what Gitea holds if something ends up out of place.

Let me know how it goes.

Released in v3.32.0. What changed: - Editing a repository's destination now asks whether to move the mirror on Gitea too (ticked by default). For an organization there is a checkbox in the destination popover and a confirmation that lists what will move. The target org is created if it does not exist. If your token cannot create repositories under the new owner, Gitea holds the transfer until one of its owners accepts it; sync keeps working at the old place until then and follows the mirror afterwards. - Sync now finds a mirror you moved by hand in Gitea instead of failing, and Retry no longer creates a second copy. Reconcile (Configuration > Automation) lists moved mirrors and can record their new location. Copies made by an earlier Retry show up there under "not managed" so you can delete them in Gitea yourself. Please go ahead and test it, but take a backup of everything first: `data/gitea-mirror.db` and your Gitea instance, or at least the repositories you are going to move. The transfer path was built from Gitea's API and unit tests, and I have not yet run it against a live Gitea, so treat it as untested until you have. The app never deletes anything on either side, and the Reconcile dialog can put the rows back in step with what Gitea holds if something ends up out of place. Let me know how it goes.

adam commented

2026-10-05 01:45:24 +02:00

That was quick, really cool that when I copy-paste author/repo, that it automatically divides in to the corresponding correct sections.

However the changing of mirror organization didn't work though.. I tried to re-add a repository, got the usual warning that "repo already exist" and I hit OK. Then tried to sync it, and immediately got "Failed"..

Looking at it on Gitea end, it is in sync-loop.. Tried hitting sync again, but keeps failing on gitea, stuck at "Migrating from …"

That was quick, really cool that when I copy-paste author/repo, that it automatically divides in to the corresponding correct sections. However the changing of mirror organization didn't work though.. I tried to re-add a repository, got the usual warning that "repo already exist" and I hit OK. Then tried to sync it, and immediately got "Failed".. Looking at it on Gitea end, it is in sync-loop.. Tried hitting sync again, but keeps failing on gitea, stuck at "Migrating from …"

adam commented

2026-10-05 01:45:25 +02:00

@Ratasan64 Thanks for testing so quickly, and glad the paste works for you.

Two different things may be tangled here, so let me separate them.

Re-adding through the Add Repository dialog does not move anything. Continuing past "Repository already exists" only refreshes the row's metadata and its destination label. The move lives in the pencil icon on the repository row (Repositories page, the destination column) and in the organization's destination popover: both ask "Move the mirror to X" and only then call Gitea's transfer API. The dialog does not say that yet, which is confusing.

"Migrating from …" on the Gitea side is a stuck migration, not a sync. Gitea shows that page when a migrate request started and never finished, and no sync can run against a repository in that state, which is why Sync fails at once. To work out how it got there I need a few things:

The version in the sidebar (3.32.0 or 3.32.1).
The error text for the failed sync from the Activity Log, and the error line on the repository row.
On Gitea: which owner the stuck repository is under (old org or new one), whether a copy still exists under the other org, what the migrating page says (Gitea shows either "in progress" or "failed" with a reason), and the Gitea or Forgejo version.
Anything you did in Gitea between the two attempts, for example deleting or transferring the old mirror by hand.

To get unstuck now: once Gitea reports the migration as failed, the repository's migrating page offers "Delete this repository" (site administration can delete it as well). When it is gone, press Retry in the app. Retry now looks for an existing mirror of the same source first, so if the old copy still exists it is recorded instead of duplicated, and if none exists a new one is created. Reconcile (Configuration, Automation) shows the state of both orgs before you touch anything.

If the stuck copy was created by Retry and Gitea gave up mid-migration, the Gitea log around that time is what I need most; a large repository or LFS content often hits a reverse proxy timeout there.

@Ratasan64 Thanks for testing so quickly, and glad the paste works for you. Two different things may be tangled here, so let me separate them. **Re-adding through the Add Repository dialog does not move anything.** Continuing past "Repository already exists" only refreshes the row's metadata and its destination label. The move lives in the pencil icon on the repository row (Repositories page, the destination column) and in the organization's destination popover: both ask "Move the mirror to X" and only then call Gitea's transfer API. The dialog does not say that yet, which is confusing. **"Migrating from …" on the Gitea side is a stuck migration, not a sync.** Gitea shows that page when a migrate request started and never finished, and no sync can run against a repository in that state, which is why Sync fails at once. To work out how it got there I need a few things: 1. The version in the sidebar (3.32.0 or 3.32.1). 2. The error text for the failed sync from the Activity Log, and the error line on the repository row. 3. On Gitea: which owner the stuck repository is under (old org or new one), whether a copy still exists under the other org, what the migrating page says (Gitea shows either "in progress" or "failed" with a reason), and the Gitea or Forgejo version. 4. Anything you did in Gitea between the two attempts, for example deleting or transferring the old mirror by hand. To get unstuck now: once Gitea reports the migration as failed, the repository's migrating page offers "Delete this repository" (site administration can delete it as well). When it is gone, press Retry in the app. Retry now looks for an existing mirror of the same source first, so if the old copy still exists it is recorded instead of duplicated, and if none exists a new one is created. Reconcile (Configuration, Automation) shows the state of both orgs before you touch anything. If the stuck copy was created by Retry and Gitea gave up mid-migration, the Gitea log around that time is what I need most; a large repository or LFS content often hits a reverse proxy timeout there.

adam commented

2026-10-05 01:45:26 +02:00

Ahh wonderful, that worked flawlessly!Ahh wonderful, that worked flawlessly!

Ahh wonderful, that worked flawlessly!Ahh wonderful, that worked flawlessly!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/gitea-mirror#163