Re: merge doesn't remove files

From: Shawn O. Pearce <spearce@spearce.org>
Date: Feb 4, 2007, 04:59 UTC
Message-ID: <20070204045933.GC16766@spearce.org>
In-Reply-To: <7vd54qzoka.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

> Having said that, I think there is a worse problem with
> merge-recursive.  It loses untracked files that are not
> involved in the merge.

I tracked it down to my commit 8371234e which was supposed to fix the bug that started this thread.

Apparently what I did was make merge-recursive remove the file from the working directory if it was renamed, even though it wasn't in the index when the merge started.

So merge-recursive is only deleting untracked files which are in the merge base, but aren't in one of the heads involved in the merge.

I'm looking at patching this. Clearly we should only delete the old file from the working directory during a rename if the tree-ish which was supposed to match the working directory had the file in it. But that tree-ish doesn't have to be the first non-base argument to merge-recursive, does it? In practice it usually is, but can I assume it in the code?

I'm looking at something like the following:

diff --git a/merge-recursive.c b/merge-recursive.c
index fa320eb..bbb52a7 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -891,7 +891,7 @@ static int process_renames(struct path_list *a_renames,
                        struct diff_filespec src_other, dst_other;
                        int try_merge, stage = a_renames == renames1 ? 3: 2;
 
-                       remove_file(1, ren1_src, index_only);
+                       remove_file(1, ren1_src, index_only || stage == 3);
 
                        hashcpy(src_other.sha1, ren1->src_entry->stages[stage].s
                        src_other.mode = ren1->src_entry->stages[stage].mode;

-- 
Shawn.