On 7/30/09 12:03 AM, "Junio C Hamano" <gitster@xxxxxxxxx> wrote:
> Josh ben Jore <jbenjore@xxxxxxxxxxxxxx> writes:
>
>> I know more now.
>
> Thanks. The log was a bit hard to read with linewrapping; here is what I
> could glean out of it anyway.
Sorry about that. I didn't realize it was wrapped. I thought I'd use my
work's Outlook since I was addressing a problem for work.
> Since I do not have an access to exact details, nor reproducible history,
> this is shot in the dark, but I think this may fix it.
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.
> 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