我们的开发团队已经被迫多次将git存储库转移到新的托管服务(从GitHub云到内部部署的BitBucket，然后到使用不同uri的BitBucket，很快到内部部署的GitLab)。
对于当前的SW版本，可以通过更改子模块的uri来处理子模块。然而，我们还需要能够使用可能的新工具链为新客户构建旧的软件版本，并且检出那些旧版本会导致问题，因为旧的uri仍然存在。
为了能够用新的构建配置构建旧的软件版本，我们有一种"元构建存储库"。在软件之上。
但是很明显，旧的软件版本仍然会有过时的子模块uri。我们肯定不是第一批遇到这种情况的人。然而，我找不到任何好的方法来解决这个问题。
我认为一个解决方案可能是使用"元构建报告";配置+ "inject"(覆盖)提交的存储库uri。一个缺点是"发布结帐";会很"脏"。
- 这是一个可行的方法吗?
- 是否有更好的方法，我没有设法找到?
我认为cmake的ExternalProject()或依赖管理(例如使用Conan.io)可能会有所帮助(而不是使用git子模块)，但这些功能/工具可能会受到先前签入的uri的影响(除了那些在"元构建报告"中处理的)。
我知道有一些选项可以重写git历史，从而回顾性地更改所有子模块的uri，但我宁愿避免这样做，因为我不知道所有的后果，例如更改提交哈希会引入
对于我的项目，我使用子模块的相对引用。如果所有的repos总是在同一个域中，这通常是有效的。例如，我将使用../repo作为同一项目中的子模块，而不是ssh://git@server/proj/repo，或者使用../proj/repo作为同一服务器上的子模块，但在不同的项目中。
这只会在服务器到服务器或项目到项目的过程中起作用，但在某些情况下，如果单个的repos被重命名或在项目之间移动，则不起作用。不过，由于看起来您只是从一个服务器重新定位到另一个服务器，所以它可能有效。
正如Jonathon提到的，看看是否可以为子模块使用相对引用是有意义的。如果将来你需要再次更改主机提供商，或者你的仓库的URL发生了变化，这样做会对你有所帮助。
你应该考虑是否有可能重写你的整个历史记录来反映这些变化。你可以看看git filter-repo(https://github.com/newren/git-filter-repo/)和git rebase -pi。
重写整个历史记录是有风险的，并且有很多陷阱，但一般的想法是，每次添加子模块时更改子模块路径，假设您保留了所有子模块的历史记录。
如果已经有可能开始使用相对引用，这是值得研究的。