Skip to content
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

Open
treyharris opened this issue Jan 23, 2020 · 5 comments
Labels
bug Something isn't working

Comments

@treyharris
Copy link

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
Copy link
Author

treyharris commented Jan 23, 2020

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
Copy link
Author

treyharris commented Jan 23, 2020

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
Copy link
Member

tarsius commented Jan 23, 2020

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.

@tarsius tarsius added the bug Something isn't working label Feb 17, 2020
@unhammer
Copy link

unhammer commented Sep 1, 2021

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
Copy link
Member

tarsius commented Sep 4, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants