1

我遇到了这个邮件列表帖子中描述的问题。当还原提交后跟合并提交时，“git subtree split”无法重建历史记录。我稍微调整了 Fabien 在他的邮件列表帖子中提供的测试脚本：

git init

# create a directory that is going to be split
mkdir doc
echo "TEST" > doc/README
git add doc
# commit A
git commit -a -m"first version"

# create a branch with a new commit (Z)
git checkout -b test
echo "TEST" > doc/README1
git add doc/README1
git commit -a -m"added README1"
git checkout master

# modify the README file (commit B)
echo "TEST_" > doc/README
git commit -a -m"second version"

# revert the change (commit C)
echo "TEST" > doc/README
git commit -a -m"revert second version"
# or use git revert HEAD^

# split
git subtree split --prefix="doc" --branch=TARGET

# add another commit (to a file *not* in the subtree dir)
echo "BLA" > BLA
git add BLA
git commit -a -m"third version"

# adding another commit to a file in the subtree dir will "fix" things
#echo "MEH" > doc/MEH
#git add doc
#git commit -a -m"fourth version"

# the log will show the 3 commits as expected (including B and C)
GIT_PAGER= git log --oneline TARGET

# merge the test branch
git merge -m"merged test" test

# attempt to re-split; this will fail
git subtree split --prefix="doc" --branch=TARGET

# see what history split generates
git subtree split --prefix="doc" --branch=TARGET2

我发现如果还原提交之后是另一个在子树目录中进行更改的提交，则拆分将按预期工作（请参阅上面的“第四版”）。这看起来像 git-subtree 中的错误。

但是，就我而言，当然已经执行了合并，因此我无法通过添加虚拟提交来解决问题。有没有其他方法可以解决这个问题？也许是 git-subtree 源代码的快速修复补丁？

4

1 回答 1

0

我想我明白发生了什么。如果两个分支之一没有净变化，则合并提交的 id 将与另一个分支上的最后一次提交的 id 相同（将-d选项传递给git subtree split命令以查看拆分提交的新提交 id ）。在这种情况下， git-subtree 将删除合并提交。这样做是因为对于常规提交，这意味着提交不会更改子树目录中的文件。

我在想解决方案是简单地调整copy_or_skip函数以始终复制合并提交。但是，这可能会导致生成的提交历史记录与以前不同（以前忽略了不必要的合并提交），从而导致其他问题。

于 2013-08-27T13:55:44.903 回答