• J
    unpack-trees.c: look ahead in the index · 730f7284
    Junio C Hamano 提交于
    This makes the traversal of index be in sync with the tree traversal.
    When unpack_callback() is fed a set of tree entries from trees, it
    inspects the name of the entry and checks if the an index entry with
    the same name could be hiding behind the current index entry, and
    
     (1) if the name appears in the index as a leaf node, it is also
         fed to the n_way_merge() callback function;
    
     (2) if the name is a directory in the index, i.e. there are entries in
         that are underneath it, then nothing is fed to the n_way_merge()
         callback function;
    
     (3) otherwise, if the name comes before the first eligible entry in the
         index, the index entry is first unpacked alone.
    
    When traverse_trees_recursive() descends into a subdirectory, the
    cache_bottom pointer is moved to walk index entries within that directory.
    
    All of these are omitted for diff-index, which does not even want to be
    fed an index entry and a tree entry with D/F conflicts.
    
    This fixes 3-way read-tree and exposes a bug in other parts of the system
    in t6035, test #5.  The test prepares these three trees:
    
     O = HEAD^
        100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    a/b-2/c/d
        100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    a/b/c/d
        100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    a/x
    
     A = HEAD
        100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    a/b-2/c/d
        100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    a/b/c/d
        100644 blob 587be6b4c3f93f93c489c0111bba5596147a26cb    a/x
    
     B = master
        120000 blob a36b77384451ea1de7bd340ffca868249626bc52    a/b
        100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    a/b-2/c/d
        100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    a/x
    
    With a clean index that matches HEAD, running
    
        git read-tree -m -u --aggressive $O $A $B
    
    now yields
    
        120000 a36b77384451ea1de7bd340ffca868249626bc52 3       a/b
        100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0       a/b-2/c/d
        100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 1       a/b/c/d
        100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 2       a/b/c/d
        100644 587be6b4c3f93f93c489c0111bba5596147a26cb 0       a/x
    
    which is correct.  "master" created "a/b" symlink that did not exist,
    and removed "a/b/c/d" while HEAD did not do touch either path.
    
    Before this series, read-tree did not notice the situation and resolved
    addition of "a/b" and removal of "a/b/c/d" independently.  If A = HEAD had
    another path "a/b/c/e" added, this merge should conflict but instead it
    silently resolved "a/b" and then immediately overwrote it to add
    "a/b/c/e", which was quite bogus.
    
    Tests in t1012 start to work with this.
    Signed-off-by: NJunio C Hamano <gitster@pobox.com>
    730f7284
diff.c 98.1 KB