git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: Patrick Steinhardt <ps@pks.im>,
	 git@vger.kernel.org,  jltobler@gmail.com
Subject: Re: [PATCH v3 4/5] maintenance: add checking logic in `pack_refs_condition()`
Date: Fri, 07 Nov 2025 08:41:19 -0800	[thread overview]
Message-ID: <xmqqo6pdg5hs.fsf@gitster.g> (raw)
In-Reply-To: <CAOLa=ZT6CnTRz5bX+Vv7pb_3oqV0XNSMEzh=57sF6O5bFYxWhQ@mail.gmail.com> (Karthik Nayak's message of "Fri, 7 Nov 2025 07:58:21 -0800")

Karthik Nayak <karthik.188@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> 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.
>>
>
> I could only find
>
>   - Some clever tricks, like using the !! operator with arithmetic
>      constructs, can be extremely confusing to others.  Avoid them,
>      unless there is a compelling reason to use them.
>
> I think its okay? This is more of a suggestion than a rule.

"Unless there is a reason to use" sounds like an outright
prohibition to me, though.

By the way, in the on-topic part of the discussion, "required" is a
bool, the helper function that takes &required takes a pointer to a
bool, and the function in question returns a bool.  So I should
update my preference above.  "return required" is the most natural
way to write, and it uses "bool" as it was designed to be used.
When the reader knows that required is a bool already, "return
!!required" is just as pointless as "return required == true".

If required and the helper that takes a pointer to it were "int",
and this function returns a bool, then my original preference would
apply; even if an "int required" has 3 in it, we probably can still
say "return required" and the function would coerce that 3 into
"true", but manually coercing it to 0/1 with !!required is more
explicit and less confusing.

Thanks.


  reply	other threads:[~2025-11-07 16:41 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
2025-11-07 15:58         ` Karthik Nayak
2025-11-07 16:41           ` Junio C Hamano [this message]
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=xmqqo6pdg5hs.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).