Josh ben Jore <jbenjore@xxxxxxxxxxxxxx> 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.
>> 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
--
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