git's -X "theirs" 不处理新的/删除的文件冲突吗？

Question

根据this 问题的场景，我正在执行git rebase -s recursive -X theirs etc... 并且惊讶地因以下类型的冲突而停止：

• 由他们添加
• 被他们删除了
• 已被我们删除

该策略是否有某些原因无法解决这些问题？

（我不知道这是否重要，但 git 不会在输出中报告冲突，它只是说When you have resolved this problem run "git rebase --continue"）

更新这是一个不能完全重现的脚本，但几乎是：

git init
git symbolic-ref HEAD refs/heads/Branch1  #just to get the 'right' branch name
echo Added in A > DeletedByThem.txt
git add -A
git commit -m A

echo Modified in B >> DeletedByThem.txt
git add -A
git commit -m B

echo Modified in C >> DeletedByThem.txt
echo Added in C > DeletedByUs.txt
git add -A
git commit -m C

git checkout -b Branch2
echo Modified in D >> DeletedByUs.txt
git rm DeletedByThem.txt
git add -A
git commit -m D

echo Modified in E >> DeletedByUs.txt
git add -A
git commit -m E

此时，你应该有这个：

Branch1:    A - B - C
                     \
Branch2:              D - E

我们想要的是这样的：

Branch1:    A - B - C
                 \
Branch2:          D - E

所以：

git rebase -s recursive -X theirs --onto [SHA of B] Branch1 Branch2

这再现了“被他们删除”和“被我们删除”的问题，但没有再现“被他们添加”，也没有任何冲突报告。

据我所知，在这种情况下，“被他们删除”意味着“在 B 之后修改，然后删除”（所以我们确实想在 Branch2 中删除它），以及“被他们删除” us”的意思是“在B之后创建”（所以我们想把它保存在Branch2中）

从我的真实（和巨大）回购的历史中可以看出，“由他们添加”与错误检测到的重命名有关（即完全不同文件夹中的相同文件被识别为重命名）。

Answer 1

您遇到冲突的原因是因为 rebase 正在尝试应用无法应用的补丁。

补丁指示我们删除的文件，找不到。

此行为是设计使然。