From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, Derrick Stolee <stolee@gmail.com>
Subject: Re: [PATCH 1/2] run-command: introduce function to prepare auto-maintenance process
Date: Wed, 17 Apr 2024 08:53:25 -0700 [thread overview]
Message-ID: <xmqq8r1c9ea2.fsf@gitster.g> (raw)
In-Reply-To: <929b6bfa08132523ee97f5adc376c3600f779a99.1713334241.git.ps@pks.im> (Patrick Steinhardt's message of "Wed, 17 Apr 2024 08:16:31 +0200")
Patrick Steinhardt <ps@pks.im> writes:
> The `run_auto_maintenance()` function is responsible for spawning a new
> `git maintenance run --auto` process. To do so, it sets up the `sturct
> child_process` and then runs it by executing `run_command()` directly.
> This is rather inflexible in case callers want to modify the child
> process somewhat, e.g. to redirect stderr or stdout.
>
> Introduce a new `prepare_auto_maintenance()` function to plug this gap.
I guess the mention of "inflexible" and "redirection" above refers
to some incompatibile behaviour we would introduce if we just
replaced the manual spawning of "gc --auto" with a call to
run_auto_maintenance(), but I would have expected that will be
solved by making the interface to run_auto_maintenance() richer, not
forcing the callers that would want to deviate from the norm to
write the second half of the run_auto_maintenance() themselves.
> +int run_auto_maintenance(int quiet)
> +{
> + struct child_process maint = CHILD_PROCESS_INIT;
> + if (!prepare_auto_maintenance(quiet, &maint))
> + return 0;
> return run_command(&maint);
> }
But given that the "second half" is to just call run_command() on
the prepared child control structure, it is probably not a huge
deal. It just felt somewhat an uneven API surface that 'quiet' can
be controlled with just a single bit and doing anything more than
that would require the caller to go into the structure to tweak.
Will queue. Thanks.
next prev parent reply other threads:[~2024-04-17 15:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 6:16 [PATCH 0/2] builtin/receive-pack: convert to use git-maintenance(1) Patrick Steinhardt
2024-04-17 6:16 ` [PATCH 1/2] run-command: introduce function to prepare auto-maintenance process Patrick Steinhardt
2024-04-17 15:53 ` Junio C Hamano [this message]
2024-04-18 5:48 ` Patrick Steinhardt
2024-04-17 6:16 ` [PATCH 2/2] builtin/receive-pack: convert to use git-maintenance(1) Patrick Steinhardt
2024-04-17 16:50 ` Karthik Nayak
2024-04-17 16:19 ` [PATCH 0/2] " Karthik Nayak
2024-04-17 16:53 ` Junio C Hamano
2024-04-18 5:43 ` Patrick Steinhardt
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=xmqq8r1c9ea2.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
--cc=stolee@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.