Our dev team has been compelled for several times to move git repositories to a new hosting service (from GitHub cloud to on-premise BitBucket, then to BitBucket with different URIs, and soon to on-premise GitLab).

Now for the current SW versions, submodules can be handled by changing the submodule's URIs. However, we also need to be able to build old software releases for new customers with possibly new toolchains, and checking out those old versions would cause problems because the old URIs are still there.

To be able to build old software releases with new build configurations, we have a kind of "meta build repository" on top of the software.

But obviously, old software releases will still have their outdated submodule URIs. We are for sure not the first ones to encounter such a scenario. However I couldn't find any good-practice approaches the tackle the problem.

I think that a solution might be to use the "meta build repo" to configure "inject" (override) the committed repository URIs. A drawback would be that the "release checkouts" would be "dirty".

• Is this a viable approach?
• Are there better approaches that I didn't manage to find out?

I thought that cmake's ExternalProject() or dependency management (e.g. with Conan.io) might be helpful (instead of using git submodules), but also those functions/tools would probably suffer from previously checked-in URIs (except those are handled in the "meta build repo").

I'm aware that there are options to rewrite the git history and thus change all the submodule URIs retrospectively, but would rather avoid that because I'm not aware of all the consequences that e.g. changed commit hashes are introducing.

CodePudding user response：

For my projects, I use relative references for submodules. This generally works if the all repos are always on the same domain. For example, instead of ssh://git@server/proj/repo, I would use ../repo for a submodule in the same project or ../proj/repo for a submodule on the same server but in a different project.

This will only work if the repos are being moved server-to-server or project-to-project, but will not work if the individual repos are being renamed or moved between projects in some cases. Although, since it looks like you are just relocating from server-to-server, it may work.

CodePudding user response：

As Jonathon mentions it would make sense to see if you can use relative references for your submodules. Doing this going forward will help you in the future if you ever need to change your hosting provider again, or the URL for your repo changes.

You should consider if it's possible to rewrite your entire history to reflect these changes. You can take a look at git filter-repo (https://github.com/newren/git-filter-repo/) and possible git rebase -pi.

Rewriting your entire history is risky, and there are many pitfalls, but the general idea would be to, change the submodule path every time a submodule have been added, assuming that you carry over the history for all the submodules.

It would be worth investigating if it's possible to already there start using relative references.