Redirect from old repository address after transferring ownership

[jmtaylor]

I transferred ownership of a personal repository from one workspace to another. Under those circumstances, am I right that push/pull with the old address should still work transparently (i.e. it should redirect to the new one)? I have admin rights over the new repository/workspace, as well as being owner of the old workspace. From these old posts:

https://community.atlassian.com/forums/Bitbucket-questions/Bitbucket-old-ssh-URL-doesnt-change-after-renaming-the/qaq-p/1124814

https://community.atlassian.com/forums/Bitbucket-questions/What-happens-with-the-repository-s-old-remote-url-when-moving-a/qaq-p/1109070

I had expected that this redirect would work, but it is not working. If I push/pull to the old repository from the command line I get this error:

remote: You may not have access to this repository or it no longer exists in this workspace. If you think this repository exists and you have access, make sure you are authenticated.

Is there something I need to do differently to activate this redirect feature? It would save a lot of hassle if that redirect was possible. The project was a submodule in a parent project, and I can’t see any way that past commits from the parent project can be matched up with the correct submodule commit (via ‘git submodule update’) unless the original workspace link still works transparently as a redirect (as I had been anticipating that it would). Can anyone advise? Thanks.

[Mark C]

Hi @jmtaylor

Welcome to the community.

After transferring a repository from one workspace to another, you will also need to update your local Git configuration specifically your Git remote URL.

This way, it points to the correct workspace you'd like to push/pull changes.

You can check our documentation here for more information: https://support.atlassian.com/bitbucket-cloud/docs/change-a-workspace-id/#Update-the-URL-in-your-configuration-file

Regards,
Mark C

[jmtaylor]

Thanks for your reply Mark. I am aware of that. As I explained, because my project is used as a submodule in another project I am not aware of any way I can simply "update the remote URL" and have things work entirely seamlessly including with historical commits. That is why I was asking about the transparent redirect, which my links above imply used to be a thing. Is that redirect from the old repository no longer implemented by bitbucket?

Reasons this is not seamless for submodules:

- The submodule in question is actually not used at all in the latest main branch of the project, and therefore there is actually no git remote URL to update. As a workaround I can add the submodule back in to .gitmodules in the main branch, so that the submodule is configured correctly when later checking out historical commits that do reference it, but this is a bit inelegant (and uses almost a GB of unnecessary disk space on the main branch that does not reference this submodule).

- As a minor point, this approach means it is essential 'git submodule init' is run on the main branch. You can't directly clone a historical branch or commit and run 'git submodule init' on that, or it references the old submodule repository.

If you have any insight into workarounds I can implement for those issues, that would be great. But the bitbucket feature of transparent repository redirect (linked in my OP) seems like it would avoid these issues.