+ * The reason we need to worry about directory/file
+ * conflicts only in #2ALT and #3ALT case is this:
+ *
+ * (1) For all other cases that read-tree internally
+ * resolves a path, we always have such a path in
+ * *both* stage2 and stage3 when we begin.
+ * Traditionally, the behaviour has been even
+ * stricter and we did not resolve a path without
+ * initially being in all of stage1, 2, and 3.
+ *
+ * (2) When read-tree finishes, all resolved paths (i.e.
+ * the paths that are in stage0) must have come from
+ * either stage2 or stage3. It is not possible to
+ * have a stage0 path as a result of a merge if
+ * neither stage2 nor stage3 had that path.
+ *
+ * (3) It is guaranteed that just after reading the
+ * stages, each stage cannot have directory/file
+ * conflicts on its own, because they are populated
+ * by reading hierarchy of a tree. Combined with
+ * (1) and (2) above, this means that no matter what
+ * combination of paths we take from stage2 and
+ * stage3 as a result of a merge, they cannot cause
+ * a directory/file conflict situation (otherwise
+ * the "guilty" path would have already had such a
+ * conflict in the original stage, either stage2
+ * or stage3). Although its stage2 is synthesized
+ * by overlaying the current index on top of "our
+ * head" tree, --emu23 case also has this guarantee,
+ * by calling add_cache_entry() to create such stage2
+ * entries.
+ *
+ * (4) Only #2ALT and #3ALT lack the guarantee (1).
+ * They resolve paths that exist only in stage2
+ * or stage3. The stage2 tree may have a file DF
+ * while stage3 tree may have a file DF/DF. If
+ * #2ALT and #3ALT rules happen to apply to both
+ * of them, we would end up having DF (coming from
+ * stage2) and DF/DF (from stage3) in the result.
+ * When we attempt to resolve a path that exists
+ * only in stage2, we need to make sure there is
+ * no path that would conflict with it in stage3
+ * and vice versa.