From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Karthik Nayak <karthik.188@gmail.com>,
git@vger.kernel.org, jltobler@gmail.com
Subject: Re: [PATCH v3 4/5] maintenance: add checking logic in `pack_refs_condition()`
Date: Thu, 06 Nov 2025 07:24:20 -0800 [thread overview]
Message-ID: <xmqqpl9vjiaj.fsf@gitster.g> (raw)
In-Reply-To: <aQyNSOdPWAxm15U3@pks.im> (Patrick Steinhardt's message of "Thu, 6 Nov 2025 12:58:00 +0100")
Patrick Steinhardt <ps@pks.im> writes:
>> + /* Check for all refs, similar to 'git refs optimize --all'. */
>> + string_list_append(optimize_opts.includes, "*");
>> +
>> + if (refs_optimize_required(get_main_ref_store(the_repository),
>> + &optimize_opts, &required))
>> + return 0;
>> +
>> + clear_ref_exclusions(&excludes);
>> + string_list_clear(&included_refs, 0);
>> +
>> + return required == true;
>
> Tiny nit: I think in our codebase this can be written in a more
> idiomatic way by saying `!!required`.
Comparing for equality with Boolean in general is stupid, as
Booleans are designed to be usable as-is. If it is "true", it is
true, and you do not have to compare it with "true" to ascertain
that it is true.
I do 100% prefer "!!required" over "required == true" or "required
!= false" all the time, since it is more idiomatic, but I vaguely
recall we had something that contradicts it in the CodingGuidelines
document. Perhaps we'd want to fix that.
Thanks.
[Footnote]
But doesn't your suggested rewrite potentially change the meaning?
The original allows required to be "true" and nothing else, while
"!!required" allows it to be any form of true (and in C, things that
are not zero, even a pointer that is not NULL, are all true).
next prev parent reply other threads:[~2025-11-06 15:24 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-31 14:22 [PATCH 0/5] maintenance: add an 'is-needed' subcommand Karthik Nayak
2025-10-31 14:22 ` [PATCH 1/5] reftable/stack: return stack segments directly Karthik Nayak
2025-10-31 16:22 ` Justin Tobler
2025-11-03 15:05 ` Karthik Nayak
2025-11-03 18:03 ` Justin Tobler
2025-10-31 14:22 ` [PATCH 2/5] reftable/stack: add function to check if optimization is required Karthik Nayak
2025-10-31 17:02 ` Justin Tobler
2025-10-31 18:17 ` Junio C Hamano
2025-11-03 16:20 ` Karthik Nayak
2025-11-03 15:51 ` Karthik Nayak
2025-11-03 17:59 ` Justin Tobler
2025-11-03 14:00 ` Patrick Steinhardt
2025-11-03 16:35 ` Karthik Nayak
2025-10-31 14:22 ` [PATCH 3/5] refs: add a `optimize_required` field to `struct ref_storage_be` Karthik Nayak
2025-10-31 14:22 ` [PATCH 4/5] maintenance: add checking logic in `pack_refs_condition()` Karthik Nayak
2025-11-03 14:00 ` Patrick Steinhardt
2025-11-03 17:04 ` Karthik Nayak
2025-10-31 14:22 ` [PATCH 5/5] maintenance: add 'is-needed' subcommand Karthik Nayak
2025-11-03 14:00 ` Patrick Steinhardt
2025-11-03 17:18 ` Karthik Nayak
2025-11-04 5:54 ` Patrick Steinhardt
2025-11-04 8:28 ` Karthik Nayak
2025-11-04 8:43 ` [PATCH v2 0/5] maintenance: add an " Karthik Nayak
2025-11-04 8:43 ` [PATCH v2 1/5] reftable/stack: return stack segments directly Karthik Nayak
2025-11-04 8:43 ` [PATCH v2 2/5] reftable/stack: add function to check if optimization is required Karthik Nayak
2025-11-04 20:26 ` Junio C Hamano
2025-11-05 14:11 ` Karthik Nayak
2025-11-05 18:10 ` Junio C Hamano
2025-11-06 8:18 ` Karthik Nayak
2025-11-04 8:43 ` [PATCH v2 3/5] refs: add a `optimize_required` field to `struct ref_storage_be` Karthik Nayak
2025-11-04 8:43 ` [PATCH v2 4/5] maintenance: add checking logic in `pack_refs_condition()` Karthik Nayak
2025-11-04 8:44 ` [PATCH v2 5/5] maintenance: add 'is-needed' subcommand Karthik Nayak
2025-11-04 15:43 ` [PATCH v2 0/5] maintenance: add an " Junio C Hamano
2025-11-05 14:00 ` Karthik Nayak
2025-11-06 8:22 ` [PATCH v3 " Karthik Nayak
2025-11-06 8:22 ` [PATCH v3 1/5] reftable/stack: return stack segments directly Karthik Nayak
2025-11-06 8:22 ` [PATCH v3 2/5] reftable/stack: add function to check if optimization is required Karthik Nayak
2025-11-06 18:18 ` Junio C Hamano
2025-11-07 6:06 ` Patrick Steinhardt
2025-11-06 8:22 ` [PATCH v3 3/5] refs: add a `optimize_required` field to `struct ref_storage_be` Karthik Nayak
2025-11-06 8:22 ` [PATCH v3 4/5] maintenance: add checking logic in `pack_refs_condition()` Karthik Nayak
2025-11-06 11:58 ` Patrick Steinhardt
2025-11-06 13:04 ` Karthik Nayak
2025-11-06 15:24 ` Junio C Hamano [this message]
2025-11-07 15:58 ` Karthik Nayak
2025-11-07 16:41 ` Junio C Hamano
2025-11-07 15:58 ` Karthik Nayak
2025-11-06 8:22 ` [PATCH v3 5/5] maintenance: add 'is-needed' subcommand Karthik Nayak
2025-11-06 12:02 ` Patrick Steinhardt
2025-11-06 13:07 ` Karthik Nayak
2025-11-08 21:51 ` [PATCH v4 0/5] maintenance: add an " Karthik Nayak
2025-11-08 21:51 ` [PATCH v4 1/5] reftable/stack: return stack segments directly Karthik Nayak
2025-11-08 21:51 ` [PATCH v4 2/5] reftable/stack: add function to check if optimization is required Karthik Nayak
2025-11-08 21:51 ` [PATCH v4 3/5] refs: add a `optimize_required` field to `struct ref_storage_be` Karthik Nayak
2025-11-08 21:51 ` [PATCH v4 4/5] maintenance: add checking logic in `pack_refs_condition()` Karthik Nayak
2025-11-08 21:51 ` [PATCH v4 5/5] maintenance: add 'is-needed' subcommand Karthik Nayak
2025-11-10 6:46 ` [PATCH v4 0/5] maintenance: add an " 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=xmqqpl9vjiaj.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jltobler@gmail.com \
--cc=karthik.188@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).