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

From: Elijah Newren <newren@gmail.com>
Date: Jul 8, 2010, 04:34 UTC
Message-ID: <AANLkTim1thwRF5boWeuhRsKpnY3DHAHq1ixIB-5GBIYA@mail.gmail.com>
In-Reply-To: <7v630rt1h3.fsf@alter.siamese.dyndns.org>

On Wed, Jul 7, 2010 at 3:40 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 7 quoted lines

> 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