On Fri, 8 May 2009, Dave O wrote:
Once again, I don't really know what the implications of the index
operations that are happening here are, but the update_stages() call
in a recursive merge must be doing surprising.
After writing this, I took another look around merge-recursive.c, and
realized that all the calls to update_stages() except this one were
careful only to do it when o->call_depth was 0. This simple patch seems
to fully rectify the problem.
---
merge-recursive.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index a3721ef..f5df9b9 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -933,11 +933,12 @@ static int process_renames(struct merge_options *o,
ren1_src, ren1_dst, branch1,
branch2);
update_file(o, 0, ren1->pair->two->sha1, ren1->pair->two->mode, ren1_dst);
- update_stages(ren1_dst, NULL,
- branch1 == o->branch1 ?
- ren1->pair->two : NULL,
- branch1 == o->branch1 ?
- NULL : ren1->pair->two, 1);
+ if (!o->call_depth)
+ update_stages(ren1_dst, NULL,
+ branch1 == o->branch1 ?
+ ren1->pair->two : NULL,
+ branch1 == o->branch1 ?
+ NULL : ren1->pair->two, 1);
} else if (!sha_eq(dst_other.sha1, null_sha1)) {
const char *new_path;
clean_merge = 0;
--
1.6.3.dirty
--
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