没有-m或--reset选项的git读取树如何工作

Question

我试图弄清楚在指定多棵树但没有git read-tree或-m选项的情况下--reset的工作方式。手册页仅描述了合并时多棵树的行为。测试套件中有一个测试用例https://github.com/git/git/blob/master/t/t1008-read-tree-overlay.sh，用于测试“不合并的多树读取树”。测试用例设置了三棵树，如下所示：

初始： 100644 blob 5626abf0f72e58d7a153368ba57db4c673c0e171 a

主： 100644 blob 5626abf0f72e58d7a153368ba57db4c673c0e171 a 100644 blob f719efd430d52bcfc8566a43b2eb655688d38871 b

面： 100644 blob 5626abf0f72e58d7a153368ba57db4c673c0e171 a 100644 blob 8510665149157c2bc901848c3e0b746954e9cbd9 b/c

我期望initial，master和side的三向读取树将导致阶段0文件a，阶段2 {{ 1}}和阶段3 b，因为b/c和b之间存在冲突（实际上，这是您运行b/c或{{1 }}在这些树上），但是当不带任何选项运行时，将导致阶段0 read-tree -m initial master side，阶段0 read-tree --reset initial master side和根本没有a。如果缺少b/c选项，为什么b和b之间没有冲突？ b/c如何胜过-m（在没有b/c的情况下运行时，无论命令行上树的顺序如何，都是这种情况）？

Answer 1

我不清楚这种读取树的用途是什么，但是您没有冲突的原因是这种读取树实际上是在不合并的情况下合并了这三棵树（因此所有内容都处于第0阶段），并且不可能有相同名称的文件和目录，因此目录条目会覆盖文件条目，并从最终索引中删除b。

（unpack-trees.c中的基础代码也用于git diff-index（请参阅this comment in unpack_callback），并且在这里它想知道它是否可以跳过子树。我不确定这是否会影响非合并案例的预期行为，但是请注意，当我们读到这段代码时，将有一个dirmask和mask不匹配（因为一棵树有一个目录，另外两棵有文件）。如果stage = 0为假，The unpack_nondirectories function仅设置o->merge，在这种情况下。 （如果 last 树在此位置具有目录，则似乎行为可能有所不同，因为我们将在此处设置冲突位，然后设置continue。）