Re: Null deref in recursive merge in df73af5f667a479764d2b2195cb0cb60b0b89e3d
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:47:07
Josh ben Jore [off-list ref] writes:
It is a very accurate shot in the dark. It appears to have fixed it when applied to 0a53e9ddeaddad63ad106860237bbf53411d11a7 GIT 1.6.4. I'll be trying this against v1.6.0.4 tomorrow.
Thanks. After re-reading the patch, I am reasonably sure that it is the right fix. Earlier we fixed similar issues with bf74106 (merge-recursive: never leave index unmerged while recursing, 2009-05-09) and 0c44c94 (merge-recursive: do not die on a conflicting submodule, 2009-04-29). The former is a fix to 36e3b5e (merge-recursive: mark rename/delete conflict as unmerged, 2008-12-22) which is probably newer than 1.6.0.4 codebase, and unless you are using submodules, the latter is probalby also safe to ignore if you are cherry-picking to the ancient 1.6.0.4 codebase.
quoted
The codepath saw that one branch renamed dev-ubuntu/ stuff to dev/ at that "unmerged" path, while the other branch added something else to the same path, and decided to add that at an alternative path, and the intent of that is so that it can safely resolve the "renamed" side to its final destination. The added update_file() call is about finishing that conflict resolution the code forgets to do. merge-recursive.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)diff --git a/merge-recursive.c b/merge-recursive.c index d415c41..868b383 100644 --- a/merge-recursive.c +++ b/merge-recursive.c@@ -955,6 +955,7 @@ static int process_renames(struct merge_options *o, new_path = unique_path(o, ren1_dst, branch2); output(o, 1, "Adding as %s instead",new_path); update_file(o, 0, dst_other.sha1, dst_other.mode, new_path); + update_file(o, 0, src_other.sha1, src_other.mode, ren1_dst); } else if ((item = string_list_lookup(ren1_dst, renames2Dst))) { ren2 = item->util; clean_merge = 0;Thanks very much, Josh