Should "git-read-tree -m -u" delete files?

[Junio C Hamano <junkio@cox.net>]

>>>>> "MU" == Matthias Urlichs <smurf@smurf.noris.de> writes:

MU> The only problem I have with it is that "git-read-tree -m -u"
MU> doesn't delete files yet. To repeat my question from last week:
>>> Would it be safe to add all files for which
>>> read_tree.c:merge_cache:fn() returns zero to a "delete me" list?
MU> (files on which which then actually get deleted, of course, if g-r-t
MU> doesn't find any problems.)

As the guilty party for the "read-tree two-way semantics table"
you quoted in your "question from last week" message, I should
have replied sooner but could not.  Sorry about that [*1*].

Anyway, here are my answers.

 (1) No, merge_function[] returning zero just means "I did not
     cause anything to change the number of already processed
     entries".  When it wants to delete an entry, it explicitly
     marks the entry to be deleted by calling deleted_entry(),
     and the deletion is processed at the very end by
     check_updates() function.  Note that we do _not_ return
     zero in this case.

 (2) The part you quoted in your "last week" message is case 10;
     the current code does delete the path with -u [*2*].

 (3) There could be cases where twoway_merge() does not delete a
     clean path that _should_ be removed.  If that is the case
     then you have spotted a bug --- I would appreciate it if
     you can show a reproduction recipe.  I have looked at the
     function briefly again while writing this reply and did not
     find suspicious code that would just return 0 without
     calling deleted_entry(), though.

 (4) Using --emu23 (followed by git-merge-cache, of course),
     instead of doing "git-read-tree -m -u H M", should remove
     deleted paths as well.


[Footnote]

*1* I was on a crazy travel schedule, going just for 3 days last
week and then for another 2 days this week to Japan from US west
coast, two 10-hour roundtrip flights X-<.  Now I am back and
hopefully fully functional ;-).

*2* The part you quoted in your previous message was this.  I am
re-quoting from the original to give it a bit more context:

    Two Tree Merge
    ~~~~~~~~~~~~~~
    ...
    In this case, the "git-read-tree -m $H $M" command makes sure
    that no local change is lost as the result of this "merge".
    Here are the "carry forward" rules:

            I (index)           H        M        Result
           -------------------------------------------------------
         ...
            clean I==H  I==M
           ------------------
         ...
         10 yes   yes   N/A     exists   nothing  remove path from cache

This case is covered by this test in t1002:

    test_expect_success \
        '10 - path removed.' \
        'rm -f .git/index &&
         echo rezrov >rezrov &&
         git-update-cache --add rezrov &&
         git-read-tree -m -u $treeH $treeM &&
         git-ls-files --stage >10.out &&
         cmp M.out 10.out &&
         sha1sum -c M.sha1'

Where paths involved are:

	path		treeH		treeM
       -----------------------------------------------------
        bozbar		exists		modified from treeH
        frotz		does not exist	added in treeM
        nitfol		exists		same as in treeH
        rezrov		exists		deleted in treeM

and after this test runs, you can see that the path "rezrov"
gets removed from your work tree.  Insert "exit" just before the
next test, run "cd t && sh t1002-*.sh -i -v", and inspect what
is in the "t/trash" directory.