在重写子模块的历史记录之后，存储库具有子模块 [英] Repository with submodules after rewriting history of submodule

问题描述

使用 git filter-branch 重写版本库的历史记录后，所有SHA都会更改。

现在，如果该存储库（我们称之为 X ）被用作另一个存储库中的git子模块（我们称之为 Y ），我们遇到了一个问题。

事实上， Y 知道子模块的版本 X 根据子模块中提交的SHA进行加载。由于 X 中的所有SHA现在都已更改，因此 Y 指向不再存在的SHA。

是否有方法重写 Y 的历史记录，使其指向子模块 X （在当前和过去的提交中）？

我猜想，如果旧SHA和新SHA之间存在对应关系，原则上这是可能的，但恐怕会涉及讨厌的bash脚本。

有什么更容易的吗？

解决方案

但是恐怕会涉及讨厌的bash脚本。

恐怕是这样。

有什么更容易的？

不是我所知道的。

这里有一些线索如果您仍然可以访问重写的回购库，那么它的原始历史记录（在之前之前 em> filter-branch）保存在 .git / refs / original 。

这意味着你可以循环对于旧的历史记录SHA1：

  git -C / path / to / rewritten / repo for-each-ref --format = ％（refname）refs / original 
  

如果更改仅限于一个分支，很容易新的SHA1与旧的（第一个旧的匹配重写的分支的第一次提交，第二个旧的......等等）

如果不是，你将不得不寻找一个转换为了找到一个匹配（相同的日期，理智的提交信息）

  git rev-list --all \ 
 | while read commit 
 do 
 ... 
  

确保父回购库更新它的子模块的引用：

pre $ $ coded父/回购
cd asubmodule
git fetch

这样，新的SHA1可用。

最后，您可以在父回购中执行过滤分支，查找 gitlink ，<一个href =https://stackoverflow.com/a/17442045/6309>索引中的特殊条目，匹配旧的SHA1中的一个。

对于每一场比赛，你签出子模块文件夹中的新SHA1，取回一级到父级回购，添加和提交：这将记录一个新的gitlink SHA1。

  cd parent / repo / asubmodule 
 git checkout< new SHA1> 
 cd .. 
 git add。 
 git commit -m为asubmodule记录新的SHA1
  

After rewriting the history of a repository with git filter-branch, all the SHAs change.

Now, if that repository (let's call it X) is used as a git submodule in another repository (let's call it Y), we have a problem.
Indeed, Y knows what version of the submodule X to load based on the SHA of the commit in that submodule. Since all the SHAs in X have now changed, Y points to SHAs that no longer exist.

Is there a way to rewrite the history of Y such that it points to the new commit SHAs of the submodule X (both in current and past commits)?

I would guess that given a correspondence between old SHAs and new ones, this is possible in principle, but I am afraid it would involve nasty bash scripts.
Is there anything easier?

解决方案

but I am afraid it would involve nasty bash scripts.

I am afraid it does.

Is there anything easier?

Not that I know of.
Here are some clues (not a full-fledged script) of what you would need for that script to work:

If you still have access to the rewritten repo, its original history (before the filter-branch) is kept in .git/refs/original.

That means you can loop for that old history SHA1:

 git -C /path/to/rewritten/repo for-each-ref --format="%(refname)" refs/original

If the changes were limited to one branch, you can match easily the new SHA1 with the old one (the first old one matches the first commit of the rewritten branch, the second old one... and so on)

If not, you would have to look for a revs in order to find a match (same date, sane commit message)

git rev-list --all \
  | while read commit
 do
 ...

Make sure the parent repo updates its refs for the submodule:

cd parent/repo
cd asubmodule
git fetch

That way, the new SHA1 are available.

Finally, you can do a filter-branch in the parent repo, looking for a gitlink, special entry in the index, matching one of the old SHA1.

For each match, you checkout the new SHA1 in the submodule folder, get back one level up to the parent repo, add and commit: that will record a new gitlink SHA1.

cd parent/repo/asubmodule
git checkout <new SHA1>
cd ..
git add .
git commit -m "Record new SHA1 for asubmodule"

这篇关于在重写子模块的历史记录之后，存储库具有子模块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！