Junio C Hamano <junkio@xxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html