git rebase master 特性给出(重命名/删除)冲突，git rebase -i master 特性没有

Question

我在使用 git 时遇到了一个奇怪的情况，我有一个功能分支修改了一些文件并删除了一个文件“foo.js”。当我通过“git rebase master feature”重新定位到 master 时，我遇到了以下类型的冲突:

CONFLICT (rename/delete): src/main/resources/com/blah/bar.js deleted in Change some js and renamed in HEAD. Version HEAD of src/main/resources/com/blah/bar.js left in tree.

奇怪的是，master 分支和feature 分支都没有修改bar.js，更不用说删除了。更重要的是，执行“git rebase -i master feature”不会产生冲突(选择所有“pick”时)。

一个可能的重要线索是 foo.js 和 bar.js 是相似但不完全相同的文件，稍微修改后的文件也与 foo.js 和 bar.js 相似。我唯一可以做出的疯狂猜测是，对相关 js 文件所做的一些更改以某种方式混淆了 git，认为分支中的违规提交功能包括删除 bar.js，然后重命名 foo.js(这是删除)到 bar.js。这是可能的/预期的吗？有谁知道为什么会发生这种情况？仅供引用，我在 linux mint 16 上使用 git 版本 1.8.3.2。

Answer 1

那有点不寻常，但你的诊断是正确的。

交互式 rebase 使用一系列 git cherry-pick命令。非交互式 rebase 使用 git-merge-recursive (至少在默认情况下；请参阅 git-rebase--merge 目录中的 git-core 脚本，无论它在您系统上的哪个位置，或者简单地记下 -s <strategy> 到 git rebase 的参数)以从旧提交中创建每个新提交。作为 -m 的文档/--merge说(虽然它没有提到这是默认):

       Use merging strategies to rebase. When the recursive (default)
       merge strategy is used, this allows rebase to be aware of renames
       on the upstream side.
 
       Note that a rebase merge works by replaying each commit from the
       working branch on top of the <upstream> branch. Because of this,
       when a merge conflict happens, the side reported as ours is the
       so-far rebased series, starting with <upstream>, and theirs is the
       working branch. In other words, the sides are swapped.

您可以使用 git diff -M --name-status 来确定¹ 比较可疑的提交对。如果这显示 bar.js作为D选择和 foo.js作为R命名为 bar.js ，这就是罪魁祸首。

恼人的是，没有办法设置 merge 的重命名阈值。幸运的是，解决方法是简单地运行一个交互式 rebase 并且不对命令系列进行任何更改，您可以通过以下方式进行快捷方式:

GIT_EDITOR=: git rebase -i ...

或使用 -p保留 merge 的选项(如果您有 merge ，后者会有所不同，但具有执行“隐式交互” rebase 的副作用，它只设置 GIT_EDITOR=: 并关闭 autosquash)。

---

¹-M如果您已配置 diff.renames，则不需要该选项至 true (参见 git config documentation)。 Merge-recursive 在内部设置重命名但不设置复制检测，并设置“重命名限制”中适用的第一个:您配置的 merge.renamelimit ， 如果你有;你的diff.renamelimit如果你有;或常量 1000 .