Subject: Re: [PATCH v6] merge-tree: add -X strategy option

From: Junio C Hamano <[email-masked]>
Date: Wed, 11 Oct 2023 15:19:28 -0700

Jeff King <[email-masked]> writes:

> I am happy with either, as they both resolve the "merge-tree knows
> intimate details about merge_options" issue. The patch I showed would
> require manually passing more details down to real_merge(), which is I
> guess what you are getting at with the "more work may want to go into
> it".

I was alluding more about teaching "merge-tree" various optional
behaviour merge_options represents.  In today's patch it may be
-X<options>, who knows what tomorrow's patch wants to bring
"merge-tree" to feature-parity with "merge".  And the first approach
would mean we would add xopts today to the struct, but we will be
required passing more details as we add other things.

>> It is not that much code on top of the commit that is already queued
>> in 'next', I suspect.  Perhaps something like this?
>
> This looks OK, though...
>
>> +void clear_merge_options(struct merge_options *opt UNUSED)
>> +{
>> +	; /* no-op as our copy is shallow right now */
>> +}
>
> Clearing is generally not just about copies, but any use of the struct.
> so this invites the question of whether the original non-copy struct
> should have a call to clear_merge_options() in cmd_merge_tree(). And
> ditto for every other user.

Yes, once we start leaking, somebody hopefully notice the lack of a
call to this on the original/template copy and add one.  Until then...