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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 20, 2024, 17:25 UTC
Message-ID: <xmqqy1cjgbna.fsf@gitster.g>
In-Reply-To: <386c0318-0138-47c9-9e7f-d1004277226c@delpeuch.eu>

Antonin Delpeuch <antonin@delpeuch.eu> 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.

Show 15 quoted lines

> 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.