All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
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: Thu, 12 Feb 2026 07:34:59 +0100	[thread overview]
Message-ID: <aY10kwlEVuNVP6kK@pks.im> (raw)
In-Reply-To: <xmqqo6lvuqsg.fsf@gitster.g>

On Wed, Feb 11, 2026 at 09:35:27AM -0800, Junio C Hamano wrote:
> 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 ;-).

Okay. Let me send another version then that does this clean-up on top.
Thanks!

Patrick

  reply	other threads:[~2026-02-12  6: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   ` ps/object-info-bits-cleanup Junio C Hamano
2026-02-12  6:34     ` Patrick Steinhardt [this message]
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=aY10kwlEVuNVP6kK@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jltobler@gmail.com \
    --cc=l.s.r@web.de \
    /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.