如何正确替换Git子模块？历史重写后的操作疑问及解决方案

我对一个被用作多仓库子模块的Git仓库执行了历史重写，我清楚这会破坏历史记录，导致恢复早期版本变得繁琐，但这是另一回事。

我原本以为可以通过以下步骤完成更新（重写后的仓库地址为<new-url>）：

git submodule deinit -f <path-to-submodule>
git submodule set-url -- <path-to-submodule> <new-url>
git submodule update --init <path-to-submodule>

但实际操作后，Git仍从原URL拉取文件——尽管.gitmodules和.git/config都已更新为新URL。最后我不得不改用以下步骤：

git submodule deinit -f <path-to-submodule>
git submodule set-url -- <path-to-submodule> <new-url>
git clone <new-url> <path-to-submodule>

这是Git的Bug，还是我理解错了操作方式？

2024-11-19 更新： #

问题确实出在使用了git submodule deinit命令。正确的操作步骤应为：

git submodule set-url -- <path-to-submodule> <new-url>
git submodule update --init --remote <path-to-submodule>

我添加了--remote参数以获取最新提交，因为子模块已被重写，父仓库关联的提交SHA已不存在。

2024-11-20 更新： #

遗憾的是，当一位用户完成此操作后，.gitmodules文件会被更新，但其他已拉取仓库的用户仍需手动执行相同操作，Git不会自动检测.gitmodules的变更并同步到.git/config。

内容的提问来源于stack exchange，提问作者TheRoadrunner