git - git 快速导入流的 merge 语义是什么？

Question

我编写并维护了一个名为 reposurgeon 的开源工具，它可以编辑版本控制存储库历史记录，并可用于在 VCS 之间移动项目历史记录。最近我发布了对读取 Subversion 转储文件和 repos 的全面支持。但是，reposurgeon 在一件事上做得还不够好，那就是通过复制到 git 风格的 DAG merge 来转换 Subversion 分支 merge 。

为了正确完成这一部分，我需要比我更了解 git 快速导入流中 merge 提交的语义。我的问题是关于在 merge 提交后哪个版本的内容应该是可见的。

当然， merge 提交附加的文件修改使得它们的内容在那里可见。我的问题是关于提交未触及的路径。

1. 如果一条路径仅包含 merge 祖先的一个提交链上的内容，我假设该内容应该是可见的。对吗？

2. 如果一条路径在 merge 的多个提交链中包含内容，那么哪个版本可见？

3. 如果一个文件在 merge 的某些路径上被删除，什么规则预测它何时会在 merge 修订中被删除？

Answer 1

如果我理解你的问题，你想知道在将提交的内容流式传输到快速导入时，你究竟可以使用哪些快捷方式。

据我阅读 git/fast-import.c 和手册页所知，fast-import 为来自“from”中提供的树的新提交初始化树“命令。 “filemodify”和 friend 们从那个状态开始构建将在最后提交的新树。

遇到“merge ”命令时，快速导入命令似乎根本不会改变树；如果你想包含来自 parent 而不是第一个 parent 的更改，你需要准确指定你想要引入哪些文件。你可以使用标记或对象哈希来命名其他分支文件以进行“filemodify”。

---

编辑:啊，让我们更深入地了解 git 模型。

在 git 中，一个提交指向一棵树，该树表示被跟踪的目录层次结构的全部内容，就像它在提交时所处的那样。提交不包含任何关于他们与 parent 有何不同的信息；理论上，如果需要，您可以通过比较这些树来重建差异。

merge 提交与非 merge 提交的区别仅在于它有两个或多个父项。它仍然只有一棵树，准确记录执行 merge 后的版本中的内容。它仍然没有记录任何关于它的作者如何将 parent merge 成一个 merge 版本的信息。 git log 和 git diff 等 git“瓷器”命令神奇地重建了对发生的事情的有用描述。

从概念上讲，要创建一个新的提交对象，您需要描述路径到该提交中的文件内容的完整映射。 (很多聪明之处在于使它变得高效和简单而不是糟糕。)

git fast-import 命令为常见情况提供了一个快捷方式:通常您从中导出的 VCS 可以告诉您此提交是如何形成的，作为与最近提交的某种差异在同一个分支上。在这种情况下，您可以有效地将差异编码为快速导入的流格式，以实现更简单、更快速的导入。

但您必须记住，这只是从头开始重新构建整个树的捷径。