From: Josh ben Jore <jbenjore@whitepages.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Git <git@vger.kernel.org>
Subject: Re: Null deref in recursive merge in df73af5f667a479764d2b2195cb0cb60b0b89e3d
Date: Thu, 30 Jul 2009 00:24:54 -0700 [thread overview]
Message-ID: <C69698D6.61E1C%jbenjore@whitepages.com> (raw)
In-Reply-To: <7vtz0uk5z3.fsf@alter.siamese.dyndns.org>
On 7/30/09 12:03 AM, "Junio C Hamano" <gitster@pobox.com> wrote:
> Josh ben Jore <jbenjore@whitepages.com> 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
next prev parent reply other threads:[~2009-07-30 7:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-28 22:23 Fw: Null deref in recursive merge in df73af5f667a479764d2b2195cb0cb60b0b89e3d Josh ben Jore
2009-07-29 14:11 ` Josh ben Jore
2009-07-30 7:03 ` Junio C Hamano
2009-07-30 7:24 ` Josh ben Jore [this message]
2009-07-30 7:54 ` Junio C Hamano
2009-07-31 0:38 ` [PATCH] merge-recursive: don't segfault while handling rename clashes Junio C Hamano
[not found] ` <7viqhaipg0.fsf@alter.siamese.dyndns.org>
2009-07-30 8:00 ` Null deref in recursive merge in df73af5f667a479764d2b2195cb0cb60b0b89e3d Johannes Schindelin
2009-08-18 21:35 ` Fredrik Kuivinen
2009-07-29 16:10 ` Fw: " Clemens Buchacher
2009-07-29 20:45 ` Josh ben Jore
2009-07-30 6:34 ` Fw: " Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2009-07-28 21:56 Josh ben Jore
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C69698D6.61E1C%jbenjore@whitepages.com \
--to=jbenjore@whitepages.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).