From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, "René Scharfe" <l.s.r@web.de>,
"Justin Tobler" <jltobler@gmail.com>
Subject: Re: ps/object-info-bits-cleanup
Date: Wed, 11 Feb 2026 09:35:27 -0800 [thread overview]
Message-ID: <xmqqo6lvuqsg.fsf@gitster.g> (raw)
In-Reply-To: <aYyQx8Yvx1n4W5L5@pks.im> (Patrick Steinhardt's message of "Wed, 11 Feb 2026 15:23:03 +0100")
Patrick Steinhardt <ps@pks.im> writes:
> On Tue, Feb 10, 2026 at 02:21:34PM -0800, Junio C Hamano wrote:
>> * ps/object-info-bits-cleanup (2026-01-26) 3 commits
>> - odb: drop gaps in object info flag values
>> - builtin/fsck: fix flags passed to `odb_has_object()`
>> - builtin/backfill: fix flags passed to `odb_has_object()`
>>
>> A couple of bugs in use of flag bits around odb API has been
>> corrected, and the flag bits reordered.
>>
>> Comments?
>> source: <20260126-b4-pks-read-object-info-flags-v1-0-e682a003b17c@pks.im>
>
> The discussion on this series has wound down by now, but I'm not sure
> whether anything actionable came out of it. The biggest question was
> around whether or not to use an enum as parameter or an unsigned
> integer, but there wasn't really a clear conclusion.
>
> Should I reroll this series to convert it to an enum, or should I keep
> this as-is and then we can merge this series down?
I do not think we want to go the route that was proposed in
<aXhbXQo6taM33m-1@pks.im>, but it's your call. As I said in
<xmqqa4y0jop7.fsf@gitster.g>, it would make sense to change
parameters that functions that deal with these constants to take
enum instead of unsigned, if we were to turn "#define" into enum.
It can be done on top as a clean-up if the theme of this topic were
something more substantial, but this topic largely being a clean-up
itself, I am not sure what the optics would be to have a clean-up
topic that requires further clean-up ;-).
next prev parent reply other threads:[~2026-02-11 17:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-10 22:21 What's cooking in git.git (Feb 2026, #04) Junio C Hamano
2026-02-11 14:23 ` ps/object-info-bits-cleanup (was: What's cooking in git.git (Feb 2026, #04)) Patrick Steinhardt
2026-02-11 17:35 ` Junio C Hamano [this message]
2026-02-12 6:34 ` ps/object-info-bits-cleanup Patrick Steinhardt
2026-02-11 20:46 ` What's cooking in git.git (Feb 2026, #04) Junio C Hamano
2026-02-12 10:26 ` Samuel Abraham
2026-02-12 15:56 ` Phillip Wood
2026-02-12 16:38 ` Junio C Hamano
2026-02-13 16:06 ` Phillip Wood
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=xmqqo6lvuqsg.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jltobler@gmail.com \
--cc=l.s.r@web.de \
--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 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.