Subject: Re: [PATCH v3] merge-ll: expose revision names to custom drivers

From: Junio C Hamano <[email-masked]>
Date: Sat, 20 Jan 2024 09:25:29 -0800

Antonin Delpeuch <[email-masked]> writes:

> After more testing (combining custom merge drivers with rerere) I
> realized that my patch can lead to a segmentation error. Many
> apologies for not having caught that earlier!

Ah, understandable.  The 3-way merge machinery may not even have to
work on commit objects (it can merge two trees, using another tree
as the "common ancestor" tree, just fine).

And in such a case, it is perfectly possible there is no "human
readable name"; all there is may be a tree object name.

> On 18/01/2024 23:09, Antonin Delpeuch via GitGitGadget wrote:
>> @@ -222,6 +222,12 @@ static enum ll_merge_result ll_ext_merge(const struct ll_merge_driver *fn,
>>   			strbuf_addf(&cmd, "%d", marker_size);
>>   		else if (skip_prefix(format, "P", &format))
>>   			sq_quote_buf(&cmd, path);
>> +		else if (skip_prefix(format, "S", &format))
>> +			sq_quote_buf(&cmd, orig_name);
>> +		else if (skip_prefix(format, "X", &format))
>> +			sq_quote_buf(&cmd, name1);
>> +		else if (skip_prefix(format, "Y", &format))
>> +			sq_quote_buf(&cmd, name2);
>
> The "orig_name", "name1" and "name2" pointers can be NULL at this
> stage. This can happen when the merge is invoked from rerere, to
> resolve a conflict using a previous resolution.

	sq_quote_buf(&cmd, name1 ? name1 : "(ours)");

or something like that, perhaps.