All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	Patrick Steinhardt <ps@pks.im>
Subject: Re: [PATCH 7/8] builtin/repack.c: drop `DELETE_PACK` macro
Date: Wed, 06 Sep 2023 10:05:37 -0700	[thread overview]
Message-ID: <xmqqh6o7nsf2.fsf@gitster.g> (raw)
In-Reply-To: <559b487e2ab056c79367a673188764e4cdce3c96.1693946195.git.me@ttaylorr.com> (Taylor Blau's message of "Tue, 5 Sep 2023 16:36:56 -0400")

Taylor Blau <me@ttaylorr.com> writes:

> Signed-off-by: Taylor Blau <me@ttaylorr.com>
> ---
>  builtin/repack.c | 18 ++++++++++--------
>  1 file changed, 10 insertions(+), 8 deletions(-)

The reason being...?

> @@ -130,7 +132,7 @@ static void mark_packs_for_deletion_1(struct string_list *names,
>  		 * (if `-d` was given).
>  		 */
>  		if (!string_list_has_string(names, sha1))
> -			item->util = (void*)(uintptr_t)((size_t)item->util | DELETE_PACK);
> +			item->util = (void*)1;

Presumably the literal "1" is promoted to an appropriate type
(uintptr_t) here?


    We originally planned to use the .util member to store a bitset
    to represent various attributes for each pack, and defined
    DELETE_PACK as one of the possible bits, but over the N years of
    its existence, we never found the need for the second bit.

or something?

It is not a bad idea to demote .util from a set of bits to just a
"is it NULL?" boolean, but updating the above to something like

	#define DELETE_PACK ((void*)(uintptr_t)1)
	item->util = DELETE_PACK;

may still reap the same simplification benefit without introducing
the "what is that _one_ about?  can it be _two_ without changing the
meaning or what?" puzzlement.

Other than that, everything else in the series looked quite
straight-forward and sensible.

Thanks.



  reply	other threads:[~2023-09-06 17:05 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-05 20:36 [PATCH 0/8] repack: refactor pack snapshot-ing logic Taylor Blau
2023-09-05 20:36 ` [PATCH 1/8] builtin/repack.c: extract structure to store existing packs Taylor Blau
2023-09-07  7:54   ` Jeff King
2023-09-05 20:36 ` [PATCH 2/8] builtin/repack.c: extract marking packs for deletion Taylor Blau
2023-09-07  7:59   ` Jeff King
2023-09-07 22:10     ` Taylor Blau
2023-09-05 20:36 ` [PATCH 3/8] builtin/repack.c: extract redundant pack cleanup for --geometric Taylor Blau
2023-09-07  8:00   ` Jeff King
2023-09-05 20:36 ` [PATCH 4/8] builtin/repack.c: extract redundant pack cleanup for existing packs Taylor Blau
2023-09-07  8:02   ` Jeff King
2023-09-05 20:36 ` [PATCH 5/8] builtin/repack.c: extract `has_existing_non_kept_packs()` Taylor Blau
2023-09-07  8:04   ` Jeff King
2023-09-05 20:36 ` [PATCH 6/8] builtin/repack.c: store existing cruft packs separately Taylor Blau
2023-09-07  8:09   ` Jeff King
2023-09-05 20:36 ` [PATCH 7/8] builtin/repack.c: drop `DELETE_PACK` macro Taylor Blau
2023-09-06 17:05   ` Junio C Hamano [this message]
2023-09-06 17:22     ` Taylor Blau
2023-09-07  8:19       ` Patrick Steinhardt
2023-09-07 18:16         ` Junio C Hamano
2023-09-07  8:58       ` Jeff King
2023-09-05 20:37 ` [PATCH 8/8] builtin/repack.c: extract common cruft pack loop Taylor Blau
2023-09-07  9:00 ` [PATCH 0/8] repack: refactor pack snapshot-ing logic Jeff King
2023-09-13 19:17 ` [PATCH v2 " Taylor Blau
2023-09-13 19:17   ` [PATCH v2 1/8] builtin/repack.c: extract structure to store existing packs Taylor Blau
2023-09-13 19:17   ` [PATCH v2 2/8] builtin/repack.c: extract marking packs for deletion Taylor Blau
2023-09-13 19:17   ` [PATCH v2 3/8] builtin/repack.c: extract redundant pack cleanup for --geometric Taylor Blau
2023-09-13 19:17   ` [PATCH v2 4/8] builtin/repack.c: extract redundant pack cleanup for existing packs Taylor Blau
2023-09-13 19:17   ` [PATCH v2 5/8] builtin/repack.c: extract `has_existing_non_kept_packs()` Taylor Blau
2023-09-15 10:02     ` Christian Couder
2023-09-13 19:17   ` [PATCH v2 6/8] builtin/repack.c: store existing cruft packs separately Taylor Blau
2023-09-13 19:18   ` [PATCH v2 7/8] builtin/repack.c: avoid directly inspecting "util" Taylor Blau
2023-09-13 19:18   ` [PATCH v2 8/8] builtin/repack.c: extract common cruft pack loop Taylor Blau
2023-09-13 19:44   ` [PATCH v2 0/8] repack: refactor pack snapshot-ing logic Junio C Hamano
2023-09-14  0:07     ` Jeff King
2023-09-14 10:33       ` Patrick Steinhardt
2023-09-14 11:10     ` Christian Couder
2023-09-14 18:01       ` Taylor Blau
2023-09-15  5:56         ` Christian Couder
2023-09-15 10:09   ` Christian Couder

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=xmqqh6o7nsf2.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    --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.