Re: [PATCHv3 3/6] merge-recursive: Fix D/F conflicts

[Elijah Newren <newren@gmail.com>]

On Wed, Jul 7, 2010 at 3:40 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Style aside, what happens when we cannot cleanly resolve D/F conflicts,
> i.e. when some untracked/modified paths still remain after the earlier
> removal?  We would signal conflict but at that point what happens to the
> files in the working tree that are involved in this new codepath?  They
> are already gone, I presume, and they at least match the original index
> entries, so not much is lost, but what would the recovery procedure out of
> the resulting mess?  "reset --hard"?

That's a really good point, and yes all those files are already gone.
However, isn't this already a problem with current git?  git does not
abort when it detects the D/F conflict, it simply creates the file
with an alternate name such as directory/file~branch, and then
continues processing all the other entries -- resulting in all those
same files under the directory being deleted.  So I don't think this
patch creates any new problem.

If you want to resolve such a merge by keeping the directory and the
files under it, it is possible, though not at all obvious or
straightforward:
$ git rm --cached file-that-used-to-be-dir
$ git status file-that-used-to-be-dir | grep deleted | sed -e
s/.*deleted:// | xargs git checkout $(git merge-base HEAD $(cat
.git/MERGE_HEAD)) --

I think we could fix this up, now that we have the D/F conflict
resolution being handled last: When process_df_entry() detects that
there's a directory in the way of the file that needs to be created
(and instead warns and creates it with an alternate name), it could
also restore those deleted entries at that time.  It seems like a bit
of unnecessary work to delete and then restore files, but I'm not sure
how to get around it given the basic strategy of having unpack_trees
do what it can and then trying to fix it up separately.


Elijah