-
-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Forge silently fails if owner changes after initial forge pull, even with brand-new clone #239
Comments
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:
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. |
No... if you create a brand-new repo on the old name, you get a different message on
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. |
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 |
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 |
Yes, but in my last message I said:
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. |
Steps to reproduce
(Requires access to multiple organizations or owner accounts):
https://github.com/${oldname}/${reponame}
, but you will be redirected tohttps://github.com/${newname}/$reponame}
.magit-status
and attempt to refresh issues.Expected result:
The issues, as before, now migrated to the new owner.
Actual result:
Messages:
No issues are displayed.
Continuing
magit-status
, thenF y
.Expected results:
*Messages*
referring to the new nameActual results:
Messages:
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.The text was updated successfully, but these errors were encountered: