git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Antonin Delpeuch via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org,  Antonin Delpeuch <antonin@delpeuch.eu>
Subject: Re: [PATCH v3] merge-ll: expose revision names to custom drivers
Date: Sat, 20 Jan 2024 14:49:11 -0800	[thread overview]
Message-ID: <xmqqcytvei3c.fsf@gitster.g> (raw)
In-Reply-To: <82624802-aa7f-4856-b819-9a2990b25a69@gmail.com> (Phillip Wood's message of "Sat, 20 Jan 2024 14:13:50 +0000")

Phillip Wood <phillip.wood123@gmail.com> writes:

> Thanks for working on this, I think it is a useful improvement. I
> guess '%X' and '%Y' are no worse than the existing '%A' and '%B' but I
> do wonder if we want to take the opportunity to switch to more
> descriptive names for the various parameters passed to the custom
> merge strategy. We do do this by supporting %(label:ours) modeled
> after the format specifiers used by other commands such as "git log"
> and "git for-each-ref".

Perhaps.  Unlike the --format option these commands take, the
placeholders are never typed from the command line (they always are
taken from the configuration file), so mnemonic value longer version
gives over the current single-letter ones is not as valuable, while
making the total line length longer.  So I dunno.

>> [...]
>> +will be stored via placeholder `%P`. Additionally, the names of the
>> +common ancestor revision (`%S`), of the current revision (`%X`) and
>> +of the other branch (`%Y`) can also be supplied. Those are short > +revision names, optionally joined with the paths of the file in each
>> +revision. Those paths are only present if they differ and are separated
>> +from the revision by a colon.
>
> It might be simpler to just call these the "conflict marker labels"
> without tying ourselves to a particular format. Something like
>
>     The conflict labels to be used for the common ancestor, local head
>     and other head can be passed by using '%(label:base)',
>     '%(label:ours)' and '%(label:theirs) respectively.

Yeah, that sounds like a good improvement, even if we did not use
the longhand placeholders and replaced %(label:{base,ours,theirs})
with %S, %X, and %Y.

>> @@ -222,6 +222,12 @@ static enum ll_merge_result ll_ext_merge(const struct ll_merge_driver *fn,
>
> Not part of this patch but I noticed that we're passing the filenames
> for '%A' etc. unquoted which is a bit scary.
>
>>   			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);
>
> I think you can avoid the SIGSEV problem you mentioned in your other
> email by changing this to
>
> 	sq_quote_buf(&cmd, orig_name ? orig_name, "");
>
> That would make sure the labels we pass match the ones used by the
> internal merge.

Makes sense.  That would be much better than using hardcoded string
"ours", "theirs", etc.

  parent reply	other threads:[~2024-01-20 22:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-18 14:26 [PATCH] merge-ll: expose revision names to custom drivers Antonin Delpeuch via GitGitGadget
2024-01-18 15:25 ` Kristoffer Haugsbakk
2024-01-18 15:42   ` Antonin Delpeuch
2024-01-18 15:43 ` [PATCH v2] " Antonin Delpeuch via GitGitGadget
2024-01-18 20:16   ` Junio C Hamano
2024-01-18 20:56     ` Antonin Delpeuch
2024-01-18 22:09   ` [PATCH v3] " Antonin Delpeuch via GitGitGadget
2024-01-19 20:02     ` Antonin Delpeuch
2024-01-20 17:25       ` Junio C Hamano
2024-01-20 14:13     ` Phillip Wood
2024-01-20 17:37       ` Junio C Hamano
2024-01-20 18:23         ` Phillip Wood
2024-01-20 22:49       ` Junio C Hamano [this message]
2024-01-24 20:09     ` [PATCH v4] " Antonin Delpeuch via GitGitGadget
2024-01-24 21:17       ` Junio C Hamano

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=xmqqcytvei3c.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=antonin@delpeuch.eu \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=phillip.wood123@gmail.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).