git-subtree 拉取并发症答案

【问题标题】：git-subtree pull complicationsgit-subtree 拉取并发症
【发布时间】：2012-04-04 08:59:44
【问题描述】：

我们一直试图让git-subtree 处理一个项目（使用 git 版本 1.7.9.4）并且遇到了一些复杂情况。几个月前，其他人使用此命令添加了子树：

git subtree add --prefix=foo git@example.com:foo.git master

现在foo 发生了实质性更改，我们希望合并这些更改，理想情况下将它们压缩。自导入以来，没有任何文件被修改过。

我尝试了三件事来尝试合并更改。

第一：

git subtree pull --squash -P foo git@example.com:foo.git master

抛出异常：Can't squash-merge: 'foo' was never added.

第二：

git subtree pull -P foo git@example.com:foo.git master

这可行（有点），但存在拉入所有提交的问题，并且与已修改的文件有冲突。

最后，我尝试了这个：

git pull --squash -s subtree git@example.com:foo.git  master

这给了我想要的结果，输出 Automatic merge went well; stopped before committing as requested 并且所有文件都显示为已修改（内容正确）。

理想情况下，我想继续使用第一个 git-subtree 版本并获得接近上一个版本的输出。如果我们必须始终使用最后一个版本，我们会，但我有点困惑为什么最后一个不会产生合并冲突，而中间的会产生冲突。

感谢任何帮助。

【问题讨论】：

标签： git merge git-subtree

【解决方案1】：

我遇到了同样的问题，在我的情况下，这似乎是由于初始子树提交被合并压缩到主分支中。

查看子树源我发现了这个：https://github.com/git/git/blob/master/contrib/subtree/git-subtree.sh#L224

看起来子树在你的 git 日志中查找 git-subtree-dir: foo，但没有找到合适的提交。试试git log --grep="git-subtree-dir: foo/*\$"，如果那个提交有什么奇怪的地方，比如它是一个合并提交，那可能就是问题所在。

除了烦人的合并冲突之外，仅拉而不挤压对我有用。我在一个临时分支中做到了这一点，然后我将git merge --squashed 到另一个分支以避免更混乱的历史。当然，它也可以被重新定位。

【讨论】：

我遇到了同样的问题，原来是因为我在尝试拉取时缺少前缀选项中的子文件夹。将此添加为注释，因为错误消息没有给出任何有关此错误的指示，并且故障排除将我带到了这里。
谢谢，这很有用。我有一个相关的问题，我在将子树添加到子目录后移动了子目录，这似乎导致了这场比赛
我遇到了这个问题，这是由于我们的 stashweb 策略压缩了提交。我能够通过找到一个子树提交并使用git merge -s ours <commit> 将它带入历史来修复它。

【解决方案2】：

每当我对子树进行拉取时，我在 sourcetree 1.7.0 上遇到了同样的错误Can't squash-merge: 'foo' was never added.。但是，我相信我的情况有所不同，因为我使用的是子目录。

Sourcetree 执行以下操作：
git -c diff.mnemonicprefix=false -c core.quotepath=false subtree pull -P dir1\subdir1 --squash remote-repo master

显然，如果我们要在 Git Bash（Git 版本 2.6.1.windows.1）中再次尝试，它会是：
git subtree pull -P "dir1\subdir1" --squash remote-repo master

但是失败了。尽管命令语法很好，但以下操作也失败了：
git subtree pull -P dir1/subdir1 --squash remote-repo master

我发现使它工作的解决方案是使用带有以下命令的 Git Bash：
git subtree pull -P "dir1/subdir" --squash remote-repo master

我猜Git的命令行处理引擎还有一些工作要做。

【讨论】：

【解决方案3】：

如果当前克隆是部分克隆（例如，使用 --depth=1 时），也会发生这种情况。这是GitHub Actions V2 的默认值。

对于 GitHub 操作，可以在结帐步骤使用 fetch-depth: 0 时进行配置：

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout source
        uses: actions/checkout@v2
        with:
          ref: master
          fetch-depth: 0

【讨论】：

【解决方案4】：

当主存储库和子树存储库具有不同的提交集时，可能会发生这种情况。

在我的情况下，我已经从本地存储库更新了子树（使用 git subtree pull --squash -P foo local/foo.git master）并且本地存储库更改从未推送到源。

当我在此之后尝试git pull --squash -s subtree git@example.com:foo.git master 时，我开始收到错误。

只需推送子树存储库即可解决错误。

【讨论】：