git 可以在进行子树合并并且没有共同祖先时猜测合并基础是什么？

Question

我正试图了解子树合并。我们需要将一个项目用作另一个项目中的子树，然后有机会通过获取工具更新第一个项目(反之亦然(。我们的工作流程是这样的：

$ git init subtree-project
$ cd subtree-project
$ echo foo > foo.TXT
$ git add .
$ git commit -m v1
$ cd ..
$ git init main-project 
$ cd main-project
$ echo boo > boo.TXT
$ git add .
$ git commit -m v1
$ git remote add subtree ../subtree-project
$ git fetch subtree
$ git branch subtree-project-master subtree/master
$ git read-tree --prefix=subtree-directory -u subtree-project-master
$ git commit -am v2 #save a subtree in the master branch

然后subtree-project被更新(v2(。在将新的提交拉入subtree-project-master分支后，我将其作为子树(subtree-directory(合并到master分支：

$ git merge --squash -s recursive -Xsubtree=subtree-directory subtree-project-master
fatal: refusing to merge unrelated histories

为什么git在这里需要--allow-unrelated-histories标志？毕竟，我们使用子树合并，git默默地完成快进合并还不够吗？

只是为了澄清我的问题：就我对子树合并的概念的理解而言，git在这种情况下可以猜测什么可以被视为合并对象的基础blob对象。也就是说，如果main-project通过read-tree命令从subtree-project(其v1状态(借用了一个树对象(以及相关的blob对象(，那么git可以认为该blob对象是3链接的基础。

我几乎可以肯定这是一个误解，但仍需要澄清。

Answer 1

为什么git需要这里的--allow无关历史标志？

因为，就git所知，历史是不相关的。您最初的插入没有被记录为合并，而是使用无祖先读取树完成的。

相反，记录合并，

git fetch subtree
# do the first one as a handroll to show git where things go
git merge -s ours --no-commit subtree/master --allow-unrelated-histories
git read-tree -u --prefix=subtree-directory
git commit

现在git看到你在做什么，你可以告诉它再做一次：

[... time passes, subtree project changes ...]
git fetch subtree
git merge -s subtree subtree/master