Git空文件的重命名检测

我最近遇到了一个问题，一个空文件在两个分支中以不同的方式重命名，但合并后没有引起冲突

重新创建的步骤如下所示

创建一个空文件

git init
touch empty
git add empty
git commit -m "add empty file"

在分支中重命名它

git checkout -b branch
git mv empty empty-in-branch
git commit -m "empty -> empty-in-branch"

在母版中以不同的方式重命名它

git checkout master
git mv empty empty-in-master
git commit -m "empty -> empty-in-master"

将分支合并到主分支

git merge --no-commit branch

这使得消息

自动合并进展顺利；在按要求提交之前已停止

git状态

仅显示分支中的新文件

为空

。但是master中没有删除

empty，因此如果我们在这个阶段提交，我们将获得这两个文件

我希望这会被标记为需要手动解决的合并冲突（即决定保留哪个空文件）。如果原始文件不是空的，就会发生这种情况。

空文件是否有影响重命名检测的特殊之处？是否有任何参数可以添加到git merge

中，使其能够检测冲突（例如调整合并策略）？

自此提交起，在递归合并中不再考虑重命名空文件：

Git的旧版本仍然将其报告为冲突

$ git --version
git version 1.7.9.5
# ... follow OP instructions to reproduce
$ git merge --no-commit branch
CONFLICT (rename/rename): Rename "empty"->"empty-in-master" in branch "HEAD" rename "empty"->"empty-in-branch" in "branch"
Automatic merge failed; fix conflicts and then commit the result.
$ git status
# On branch master
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#   both deleted:       empty
#   added by them:      empty-in-branch
#   added by us:        empty-in-master
#
no changes added to commit (use "git add" and/or "git commit -a")

$git--版本
git版本1.7.9.5
# ... 按照操作说明进行复制
$git merge--无提交分支
冲突（重命名/重命名）：重命名分支“HEAD”中的“empty”->“empty in master”重命名“empty”->“branch”中的“empty in branch”
自动合并失败；修复冲突，然后提交结果。
$git状态
#论分行行长
#未合并路径：
#（酌情使用“git add/rm…”标记分辨率）
#
#都已删除：空
#由他们添加：分支中为空
#由我们添加：主控中为空
#
未向提交添加任何更改（使用“git add”和/或“git commit-a”）

Git不会隐式跟踪重命名，因此在没有重命名检测的情况下，最终发生的情况是Git只看到两次提交都删除了文件

为空

，并且每次提交都添加了一个新文件

有一个选项可以更改git diff（）的此行为，但当前它未在

git merge

的选项中公开

---

其他合并策略似乎也没有提供所需的行为。

有趣的行为是肯定的。不确定原因，但是。。。Git根据文件的内容存储文件。所以两个空文件在技术上被认为是相同的。由于可能会有大量的重叠，所以在这里有一些特殊的逻辑是有意义的。看起来可能会对空文件进行特殊处理。但是Git已经基于散列只存储了每个对象的一个副本，所以大量重复的空文件和大量重复的非空文件之间没有真正的区别（也就是说，显然不需要对空文件进行特殊处理）。谢谢——有用的信息。第一个链接说“这将导致合并中的修改/删除冲突，这将让用户自己进行排序”，不幸的是，这不会发生。只有当空文件添加了内容时，才会发生这种情况。您可以查看提交上的测试并查看该行为。