From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Derrick Stolee <derrickstolee@github.com>
Subject: Re: [PATCH v2 10/10] repository.h: drop unused `gc_cruft_packs`
Date: Wed, 19 Apr 2023 15:19:30 -0700 [thread overview]
Message-ID: <xmqqlein7bwt.fsf@gitster.g> (raw)
In-Reply-To: <c67ee7c2ff9456eda1c5468cf68ddb1b83d37c85.1681850424.git.me@ttaylorr.com> (Taylor Blau's message of "Tue, 18 Apr 2023 16:41:00 -0400")
Taylor Blau <me@ttaylorr.com> writes:
> As of the previous commit, all callers that need to read the value of
> `gc.cruftPacks` do so outside without using the `repo_settings` struct,
> making its `gc_cruft_packs` unused. Drop it accordingly.
>
> Signed-off-by: Taylor Blau <me@ttaylorr.com>
> ---
> repo-settings.c | 4 +---
> repository.h | 1 -
> 2 files changed, 1 insertion(+), 4 deletions(-)
This is in line with the current design of repo-settings, and it is
a total tangent to this topic, but in retrospect, if we structured
how "what's experimental" is determined in a more distributed way,
we didn't have to have this patch. That is, instead of saying "ok
we are in a repository with experimental setting turned on, and the
set of features to be enabled are centrally described in this
settings structure", each opt-in features (like the code that reads
"gc.cruftPacks" by calling git_config_get_bool() to override its
default value) can select their default/fallback values by seeing if
the experimental bit is set.
In any case, this patch looks good and we have one fewer such
centrally managed bit.
prev parent reply other threads:[~2023-04-19 22:28 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-17 20:54 [PATCH 00/10] gc: enable cruft packs by default Taylor Blau
2023-04-17 20:54 ` [PATCH 01/10] pack-write.c: plug a leak in stage_tmp_packfiles() Taylor Blau
2023-04-18 10:30 ` Jeff King
2023-04-18 19:40 ` Taylor Blau
2023-04-17 20:54 ` [PATCH 02/10] builtin/repack.c: fix incorrect reference to '-C' Taylor Blau
2023-04-17 20:54 ` [PATCH 03/10] builtin/gc.c: ignore cruft packs with `--keep-largest-pack` Taylor Blau
2023-04-17 22:54 ` Junio C Hamano
2023-04-17 23:03 ` Taylor Blau
2023-04-18 10:39 ` Jeff King
2023-04-18 14:54 ` Derrick Stolee
2023-04-17 20:54 ` [PATCH 04/10] t/t5304-prune.sh: prepare for `gc --cruft` by default Taylor Blau
2023-04-17 20:54 ` [PATCH 05/10] t/t9300-fast-import.sh: " Taylor Blau
2023-04-18 10:43 ` Jeff King
2023-04-18 19:44 ` Taylor Blau
2023-04-17 20:54 ` [PATCH 06/10] t/t6500-gc.sh: refactor cruft pack tests Taylor Blau
2023-04-17 20:54 ` [PATCH 07/10] t/t6500-gc.sh: add additional test cases Taylor Blau
2023-04-18 10:48 ` Jeff King
2023-04-18 19:48 ` Taylor Blau
2023-04-17 20:54 ` [PATCH 08/10] t/t6501-freshen-objects.sh: prepare for `gc --cruft` by default Taylor Blau
2023-04-18 10:56 ` Jeff King
2023-04-18 19:50 ` Taylor Blau
2023-04-22 11:23 ` Jeff King
2023-04-17 20:54 ` [PATCH 09/10] builtin/gc.c: make `gc.cruftPacks` enabled " Taylor Blau
2023-04-18 11:00 ` Jeff King
2023-04-18 19:52 ` Taylor Blau
2023-04-17 20:54 ` [PATCH 10/10] repository.h: drop unused `gc_cruft_packs` Taylor Blau
2023-04-18 11:02 ` Jeff King
2023-04-18 11:04 ` [PATCH 00/10] gc: enable cruft packs by default Jeff King
2023-04-18 19:53 ` Taylor Blau
2023-04-18 20:40 ` [PATCH v2 " Taylor Blau
2023-04-18 20:40 ` [PATCH v2 01/10] pack-write.c: plug a leak in stage_tmp_packfiles() Taylor Blau
2023-04-19 22:00 ` Junio C Hamano
2023-04-20 16:31 ` Taylor Blau
2023-04-20 16:57 ` Junio C Hamano
2023-04-18 20:40 ` [PATCH v2 02/10] builtin/repack.c: fix incorrect reference to '-C' Taylor Blau
2023-04-18 20:40 ` [PATCH v2 03/10] builtin/gc.c: ignore cruft packs with `--keep-largest-pack` Taylor Blau
2023-04-18 20:40 ` [PATCH v2 04/10] t/t5304-prune.sh: prepare for `gc --cruft` by default Taylor Blau
2023-04-18 20:40 ` [PATCH v2 05/10] t/t6501-freshen-objects.sh: " Taylor Blau
2023-04-18 20:40 ` [PATCH v2 06/10] t/t6500-gc.sh: refactor cruft pack tests Taylor Blau
2023-04-18 20:40 ` [PATCH v2 07/10] t/t6500-gc.sh: add additional test cases Taylor Blau
2023-04-18 20:40 ` [PATCH v2 08/10] t/t9300-fast-import.sh: prepare for `gc --cruft` by default Taylor Blau
2023-04-18 20:40 ` [PATCH v2 09/10] builtin/gc.c: make `gc.cruftPacks` enabled " Taylor Blau
2023-04-19 22:22 ` Junio C Hamano
2023-04-20 17:24 ` Taylor Blau
2023-04-20 17:31 ` Junio C Hamano
2023-04-20 19:19 ` Taylor Blau
2023-04-18 20:41 ` [PATCH v2 10/10] repository.h: drop unused `gc_cruft_packs` Taylor Blau
2023-04-19 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=xmqqlein7bwt.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
/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).