在处理二进制文件时,git 似乎会考虑用另一个文件替换一个文件,修改后的文件重命名。这发生在例如当用 foo-1.0.3.jar 或以下测试用例替换 foo-1.0.1.jar 时:
$ dd if=/dev/urandom of=test.dat bs=1024 count=10
$ md5sum test.dat
8073aef704e9df13b44818371ebbcc0b test.dat
$ git add test.dat && git commit -m 'add binary file'
$ mv test.dat test2.dat
$ git rm test.dat
$ dd if=/dev/urandom of=test2.dat bs=1 count=1 conv=notrunc
$ md5sum test2.dat
21e1ac3ab9ba50c9dad9171f9de7232d test2.dat
$ git add test2.dat
现在我显然有了一个包含新内容(至少部分)和新名称的文件。但是,git 认为这是 git status
中的重命名:
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# renamed: test.dat -> test2.dat
- 这是什么原因,例如这两个文件必须有多相似?如果 test2.dat 包含完全不同的数据,这似乎不会发生。
- 除了看起来有点笨拙外,它有什么缺点吗?实际数据似乎非常好;在检查以前的修订版时,我确实得到了该修订版的正确文件。
最佳答案
Git 实际上并不存储重命名,它只是存储一棵新树,其中一个文件被删除,另一个文件被添加。比较树的 Git 命令(git diff
、git log
、git status
)根据内容检测重命名。
出于某种原因,重命名检测会为您的文件触发。如果你耗尽了 /dev/urandom
中的熵,它们的内容可能是相似的?
编辑:参见例如How does git detect similar files, for its rename detection?有关重命名检测的详细信息。
关于git - 为什么 git-status 会显示一个更新的二进制文件,并使用新名称作为重命名?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13402612/