用例是我必须将某些存储库移动到新服务器。所以这些存储库获得了一个新的 url。
引用这些子模块的父项目需要使用子模块的新 url 进行更新。
我想做以下事情。
- 更新 .gitmodules 文件
- git 子模块同步
- git子模块更新
- 提交和推送
但是,由于以前的提交具有早期版本的 .gitmodule,如果我签出父项目的先前提交 - 它不会寻找旧服务器吗?
为了确保可重复性,我们需要让所有旧的提交都能正常工作。有什么办法解决这个问题吗?
用例是我必须将某些存储库移动到新服务器。所以这些存储库获得了一个新的 url。
引用这些子模块的父项目需要使用子模块的新 url 进行更新。
我想做以下事情。
- 更新 .gitmodules 文件
- git 子模块同步
- git子模块更新
- 提交和推送
但是,由于以前的提交具有早期版本的 .gitmodule,如果我签出父项目的先前提交 - 它不会寻找旧服务器吗?
为了确保可重复性,我们需要让所有旧的提交都能正常工作。有什么办法解决这个问题吗?
里面的 URL.gitmodules
一般只在初始化子模块或 on 时使用git submodule sync
。在初始化 ( git submodule init
) 时,URL 被放入存储库.git/config
中,当子模块被克隆到位 (on git submodule update
) 时,要使用的 URL 从配置中获取。唯一一次使用 in 的 URL.gitmodules
是在运行时git submodule sync
,这将类似地更新配置中的 URL,但也会将origin
子模块中的远程设置为相同的 URL。
这意味着您在签出较早的提交并运行时不会遇到任何问题git submodule update
- 当您在父存储库中签出新提交时,子模块中的远程origin
不会更改。
如果您需要这样做,唯一的方法是使用filter-branch。
但要小心,因为更改.gitmodules
所有提交意味着您转换了该提交。
如果您与许多开发人员共享 git 存储库,则所有开发人员都需要“强制拉取”新提交,并且基于旧提交的所有工作都需要重新定位到新分支。
有很多关于重写 git 历史的讨论。