重命名/移动修改后的文件后，Git 不跟踪历史记录

Question

问题：我需要更改存储库中整个目录的位置。 为此，我使用git mv ，如果需要，我将包含头名称更改为当前正确的名称。 问题是当我在一次提交期间采取两项行动时。 在这种情况下，文件历史记录丢失（git 认为这是删除和创建新文件）。

解决方法：如果我将这些操作拆分为单独的提交，则不会发生该问题。

问题再次出现：但是，即使我使用上述解决方案，在与 master 合并期间问题仍然存在。 我有义务只使用 no-ff 合并。 在这种情况下，对 master 分支的新提交是由两个提交和...的更改组成的。无论如何，历史记录都没有正确跟踪。

另一个丑陋的解决方法：我可以将这些提交单独交付给 master。 我无法提供不可编译的代码，但如果我将其排除在构建过程之外，它可能是可行的......但它很丑陋而且错误......

我想知道是否有更好的解决方案来解决这个问题。

Answer 1

如果您熟悉几乎所有其他版本控制系统 (VCS)，则可能很难理解 Git 对文件历史做了什么。

事实是，Git不会有文件历史记录。 它在这里的 VCS 中可能是独一无二的（尽管我对许多更神秘的 VCS 没有经验）。 它的近亲 Mercurial确实有文件历史记录：添加到 Mercurial 的每个文件都会在 Mercurial 称为manifest的文件中分配一个唯一的编号，这决定了文件的身份。 如果您更改一个文件的名称——或者一个充满文件的整个目录——它们会保留它们的身份，因为这些信息存在于清单中。

Git 完全摒弃了这个概念。 Git 根本没有文件历史记录。 Git 只有commits 。

每个提交都存储一个源树的完整快照。 每个提交也有一定数量的父提交，通常只有一个。 这更像传统的基于提交的 VCS：可以跟踪各种提交，或查看文件历史记录。 但是由于 Git 没有文件历史记录，它唯一拥有的就是提交历史记录。

为了实现git log --follow和其他有用的项目，Git 提供的不是文件历史记录，而是重命名检测。 Git 可以查看任何一个特定的提交，并将该提交与其父提交进行比较——或者对于合并提交，与它的所有父提交进行比较。 当它进行这种比较时，它提供了检测通过该提交重命名的文件的选项：在父级中具有一个名称但在子级中具有不同名称的文件。 ¹

在比较两个任意提交时，Git 甚至提供这种重命名检测，而不仅仅是父子提交。 跑步：

git diff --find-renames $hash1 $hash2

比较两次提交，并且只要有“ $hash1路径为a/b/c.txt文件看起来很像$hash1路径为d/e/f.log的$hash2 ”的$hash2 ，Git 可能会声称该文件被重命名（然后也可能被修改）。 不过，重要的是要记住，Git 只是综合了一种将第一个文件转换为第二个. 两次提交中的两个实际文件以这种方式永久存储。 它们永远无法更改：只要这些提交存在，这两个文件就会以这种方式存储在这两个提交中。 这两个文件实际上根本不相关，除非您希望它们是. Git 通过比较它们的相似性来“寻找”重命名。 给 Git 一组不同的“相似性”标准——例如， -M75%而不是-M50% ——Git 可能会选择一组不同的“足够相似”的文件。

任何提交都没有发生任何事情。 他们都被时间冻结了。 但是使用一组不同的“重命名阈值”值、“中断阈值”等，Git 可能会配对不同的路径名。 鉴于--no-renames ，Git 永远不会配对不同的路径名（尽管它仍然会配对具有相同名称的文件）。

（这种动态重命名检测很重要， git diff --find-rename在合并时很重要，因为合并运行两个git diff --find-rename操作，从合并基础提交到正在合并的两个分支提示提交中的每一个。如果 Git 找到了rename，它相信。如果没有找到rename，它认为在tip中删除了base文件，在tip中创建了不同的文件。您可以控制rename阈值，但不能设置break或copy阈值，至少在今天的 Git 版本中是 2.15。）

---

¹这是什么意思是合并提交不太清楚，因为有多个父：这是什么意思文件child.txt有过的名字p1.txt在父母＃1和p2.txt父＃2？ 传统的 VCS 以其独特的内部编号系统确定文件身份，在这里分配了明确的含义，但在实践中，这种含义并不总是有用的，Linus Torvalds 在这里选择完全取消这个概念，可能已经在部分反应。

Answer 2

您可以将--follow选项设置为git log命令的默认值：

git config --global log.follow true