# Trivial merge rules

This document describes the outcomes of the trivial merge logic in read-tree.

## One-way merge

This replaces the index with a different tree, keeping the stat info for entries that don’t change, and allowing -u to make the minimum required changes to the working tree to have it match.

Entries marked + have stat information. Spaces marked * don’t affect the result.

    index   tree    result
    -----------------------
    *       (empty) (empty)
    (empty) tree    tree
    index+  tree    tree
    index+  index   index+

## Two-way merge

It is permitted for the index to lack an entry; this does not prevent any case from applying.

If the index exists, it is an error for it not to match either the old or the result.

If multiple cases apply, the one used is listed first.

A result which changes the index is an error if the index is not empty and not up-to-date.

Entries marked + have stat information. Spaces marked * don’t affect the result.

    case  index   old     new     result
    -------------------------------------
    0/2   (empty) *       (empty) (empty)
    1/3   (empty) *       new     new
    4/5   index+  (empty) (empty) index+
    6/7   index+  (empty) index   index+
    10    index+  index   (empty) (empty)
    14/15 index+  old     old     index+
    18/19 index+  old     index   index+
    20    index+  index   new     new

## Three-way merge

It is permitted for the index to lack an entry; this does not prevent any case from applying.

If the index exists, it is an error for it not to match either the head or (if the merge is trivial) the result.

If multiple cases apply, the one used is listed first.

A result of "no merge" means that index is left in stage 0, ancest in stage 1, head in stage 2, and remote in stage 3 (if any of these are empty, no entry is left for that stage). Otherwise, the given entry is left in stage 0, and there are no other entries.

A result of "no merge" is an error if the index is not empty and not up-to-date.

empty means that the tree must not have a directory-file conflict with the entry.

For multiple ancestors, a + means that this case applies even if only one ancestor or remote fits; a ^ means all of the ancestors must be the same.

    case  ancest    head    remote    result
    ----------------------------------------
    1     (empty)+  (empty) (empty)   (empty)
    2ALT  (empty)+  *empty* remote    remote
    2     (empty)^  (empty) remote    no merge
    3ALT  (empty)+  head    *empty*   head
    3     (empty)^  head    (empty)   no merge
    4     (empty)^  head    remote    no merge
    5ALT  *         head    head      head
    6     ancest+   (empty) (empty)   no merge
    8     ancest^   (empty) ancest    no merge
    7     ancest+   (empty) remote    no merge
    10    ancest^   ancest  (empty)   no merge
    9     ancest+   head    (empty)   no merge
    16    anc1/anc2 anc1    anc2      no merge
    13    ancest+   head    ancest    head
    14    ancest+   ancest  remote    remote
    11    ancest+   head    remote    no merge

Only #2ALT and #3ALT use empty, because these are the only cases where there can be conflicts that didn’t exist before. Note that we allow directory-file conflicts between things in different stages after the trivial merge.

A possible alternative for #6 is (empty), which would make it like #1. This is not used, due to the likelihood that it arises due to moving the file to multiple different locations or moving and deleting it in different branches.

Case #1 is included for completeness, and also in case we decide to put on + markings; any path that is never mentioned at all isn’t handled.

Note that #16 is when both #13 and #14 apply; in this case, we refuse the trivial merge, because we can’t tell from this data which is right. This is a case of a reverted patch (in some direction, maybe multiple times), and the right answer depends on looking at crossings of history or common ancestors of the ancestors.

Note that, between #6, #7, #9, and #11, all cases not otherwise covered are handled in this table.

For #8 and #10, there is alternative behavior, not currently implemented, where the result is (empty). As currently implemented, the automatic merge will generally give this effect.