From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: phillip.wood@dunelm.org.uk,
Izzy via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Elijah Newren <newren@gmail.com>,
Izzy <winglovet@gmail.com>
Subject: Re: [PATCH v6] merge-tree: add -X strategy option
Date: Wed, 11 Oct 2023 15:19:28 -0700 [thread overview]
Message-ID: <xmqqedi0kdjj.fsf@gitster.g> (raw)
In-Reply-To: <20231011214340.GA518221@coredump.intra.peff.net> (Jeff King's message of "Wed, 11 Oct 2023 17:43:40 -0400")
Jeff King <peff@peff.net> 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...
prev parent reply other threads:[~2023-10-11 22:19 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-05 14:24 [PATCH] merge-tree: add -X strategy option Izzy via GitGitGadget
2023-08-07 2:10 ` Junio C Hamano
2023-08-12 5:33 ` [PATCH v2] " Izzy via GitGitGadget
2023-08-12 5:41 ` 唐宇奕
2023-09-03 1:31 ` 唐宇奕
2023-09-12 15:03 ` Elijah Newren
2023-09-16 2:14 ` [PATCH v3] " Izzy via GitGitGadget
2023-09-16 2:26 ` 唐宇奕
2023-09-16 3:21 ` Elijah Newren
2023-09-16 3:16 ` Elijah Newren
2023-09-16 3:47 ` [PATCH v4] " Izzy via GitGitGadget
2023-09-16 3:55 ` Elijah Newren
2023-09-16 4:04 ` 唐宇奕
2023-09-16 6:11 ` Jeff King
2023-09-16 8:37 ` [PATCH v5] " Izzy via GitGitGadget
2023-09-16 8:38 ` 唐宇奕
2023-09-18 9:53 ` Phillip Wood
2023-09-18 16:08 ` Junio C Hamano
2023-09-24 2:23 ` [PATCH v6] " Izzy via GitGitGadget
2023-09-24 2:26 ` 唐宇奕
2023-10-09 9:58 ` Phillip Wood
2023-10-09 15:53 ` Jeff King
2023-10-09 17:10 ` Junio C Hamano
2023-10-09 18:52 ` Jeff King
2023-10-11 19:38 ` Junio C Hamano
2023-10-11 21:43 ` Jeff King
2023-10-11 22:19 ` Junio C Hamano [this message]
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=xmqqedi0kdjj.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=newren@gmail.com \
--cc=peff@peff.net \
--cc=phillip.wood@dunelm.org.uk \
--cc=winglovet@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.