Forge silently fails if owner changes after initial forge pull, even with brand-new clone

[treyharris]

Steps to reproduce

(Requires access to multiple organizations or owner accounts):

1. Connect Forge to a GitHub repo with issues and pull them into Forge
2. Transfer ownership of the repo to a new owner (organization or user). You can now still visit https://github.com/${oldname}/${reponame}, but you will be redirected to https://github.com/${newname}/$reponame}.
3. Quit and restart Emacs.
4. Visit the repo again with magit-status and attempt to refresh issues.

Expected result:

The issues, as before, now migrated to the new owner.

Actual result:

Messages:

Pulling ${oldname}/${reponame}...done
Storing ${oldname}/${reponame}...done
Running hub fetch
Hub finished

No issues are displayed.

Continuing

1. Move aside or delete the old repo.
2. Clone the repo from its new name. Do not refer to the old name in any way.
3. Run magit-status, then F y.

Expected results:

• *Messages* referring to the new name
• A list of issues

Actual results:

Messages:

Pulling ${oldname}/${reponame}...done
Storing ${oldname}/${reponame}...done
Running hub fetch
Hub finished

No issues are displayed.

Discussion

I traced execution enough to see that the issue is apparently in the SQLite file—this is where Forge is getting sent back to the old name, even when it’s never been referred to by Git in a given repo—and I suspect I could fix the issue by doing string-replacement in the SQL tables. But I have enough work in other repos in-flight that I’d prefer not to experiment.

Note that manually updating forge.remote for the repo does not make any difference here.

[treyharris]

Note, also, that the severity of this issue is higher than it might appear given the rarity of this event; you can no longer access the repo using Forge by any of:

1. An old repo referring only to the old name using GitHub’s redirection for fetch and push requests
2. An old repo with remotes and forge.remote renamed
3. A brand-new clone to the new name with no reference to the old

all of which work fine with Magit in general.

Hm… for completeness, I should check a brand-new repo referring to the old name. I’ll edit this comment after doing that, but if it works that would reduce the severity by providing a workaround.

[treyharris]

No... if you create a brand-new repo on the old name, you get a different message on forge-pull:

Cannot determine forge repository.  ${HOME}/src/${oldname}/${reponame} isn’t a forge url

This seems strange, given that I’m following the usual remote conventions, I’d have expected it to act identically to the three cases mentioned in the prior comment. But perhaps an underlying library doesn’t deal with 302 redirects correctly in some case.

[tarsius]

This is due to a misguided early attempt to more gracefully with renamed repositories. The result is that we deal with them less gracefully. Fixing that will be a lot of work. There's another issue about this I believe but I am unable to find it. Your only option is to delete the data using forge-remove-repository and then adding it again after making sure the urls are up-to-date.

[unhammer]

Shouldn't it be possible to notice the redirect (or notice some error and then check if there's a redirect from the old url), and then ask the user if they want to remove and re-add? I don't know what the corresponding api call would be, but I'm able to curl https://github.com/oldowner/repo and get a HTTP 301 pointing at https://github.com/newowner/repo.

[tarsius]

Shouldn't it be possible to notice the redirect (or notice some error and then check if there's a redirect from the old url), and then ask the user if they want to remove and re-add?

Yes, but in my last message I said:

This is due to a misguided early attempt to more gracefully with renamed repositories. The result is that we deal with them less gracefully. Fixing that will be a lot of work.

Or in other words, we already did what you are suggesting and it backfired. Trying again is not a priority and my past statement sounds like I have already come to the conclusion that doing so would be a lot of work.