From: Taylor Blau <me@ttaylorr.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH 0/3] Small new merge-ort features, prepping for deletion of merge-recursive.[ch]
Date: Wed, 12 Mar 2025 16:05:22 -0400 [thread overview]
Message-ID: <Z9HpAgGq0FSOheLj@nand.local> (raw)
In-Reply-To: <Z9FAh5p2h55_4mki@pks.im>
On Wed, Mar 12, 2025 at 09:06:31AM +0100, Patrick Steinhardt wrote:
> On Fri, Mar 07, 2025 at 03:48:39PM +0000, Elijah Newren via GitGitGadget wrote:
> > I've got 19 patches covering the work needed to prep for and allow us to
> > delete merge-recursive.[ch], and remap 'recursive' to 'ort', including some
> > clean-up along the way. I've tried to divide it up into five smaller patch
> > series.
> >
> > These 3 patches are the first of those series, and each of these 3 patches
> > provide a small new feature that together will be used to allow us to
> > convert some callers over from recursive to ort. If the third patch,
> > introducing merge_ort_generic(), doesn't make sense to submit without one of
> > its new callers, I can extend this series to 6 patches and include the
> > conversion of git-am.sh.
>
> I think extending it to 6 patches would make sense as it's somewhat
> unfortunate that this version introduces the function, but has no
> callers at all.
Eh. I have gone back and forth about that over the years. I think in
cases where the either caller(s) or implementation is sufficiently
complicated, it's OK to introduce a (non-static) function without any
callers.
I don't feel strongly about it, so I think the multi-series structure is
fine as it is (especially since we know that more are coming in the
future). But I'm also not opposed to seeing this series extended out to
include the three additional patches.
Thanks,
Taylor
next prev parent reply other threads:[~2025-03-12 20:05 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-07 15:48 [PATCH 0/3] Small new merge-ort features, prepping for deletion of merge-recursive.[ch] Elijah Newren via GitGitGadget
2025-03-07 15:48 ` [PATCH 1/3] merge-ort: add new merge_ort_generic() function Elijah Newren via GitGitGadget
2025-03-12 8:06 ` Patrick Steinhardt
2025-03-12 20:00 ` Taylor Blau
2025-03-12 21:39 ` Elijah Newren
2025-03-07 15:48 ` [PATCH 2/3] merge-ort: allow rename detection to be disabled Elijah Newren via GitGitGadget
2025-03-12 8:06 ` Patrick Steinhardt
2025-03-12 20:02 ` Taylor Blau
2025-03-12 21:40 ` Elijah Newren
2025-03-12 21:50 ` Taylor Blau
2025-03-13 5:25 ` Jeff King
2025-03-07 15:48 ` [PATCH 3/3] merge-ort: support having merge verbosity be set to 0 Elijah Newren via GitGitGadget
2025-03-12 20:03 ` Taylor Blau
2025-03-12 21:44 ` Elijah Newren
2025-03-12 21:50 ` Taylor Blau
2025-03-12 8:06 ` [PATCH 0/3] Small new merge-ort features, prepping for deletion of merge-recursive.[ch] Patrick Steinhardt
2025-03-12 20:05 ` Taylor Blau [this message]
2025-03-13 2:46 ` [PATCH v2 0/6] " Elijah Newren via GitGitGadget
2025-03-13 2:46 ` [PATCH v2 1/6] merge-ort: add new merge_ort_generic() function Elijah Newren via GitGitGadget
2025-03-13 2:46 ` [PATCH v2 2/6] merge-ort: allow rename detection to be disabled Elijah Newren via GitGitGadget
2025-03-13 2:46 ` [PATCH v2 3/6] merge-ort: support having merge verbosity be set to 0 Elijah Newren via GitGitGadget
2025-03-13 2:46 ` [PATCH v2 4/6] t3650: document bug when directory renames are turned off Johannes Schindelin via GitGitGadget
2025-03-13 2:46 ` [PATCH v2 5/6] merge-ort: fix merge.directoryRenames=false Elijah Newren via GitGitGadget
2025-03-13 2:46 ` [PATCH v2 6/6] am: switch from merge_recursive_generic() to merge_ort_generic() Elijah Newren via GitGitGadget
2025-03-17 21:25 ` [PATCH v2 0/6] Small new merge-ort features, prepping for deletion of merge-recursive.[ch] Taylor Blau
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=Z9HpAgGq0FSOheLj@nand.local \
--to=me@ttaylorr.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=newren@gmail.com \
--cc=ps@pks.im \
/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).