threads / patch / 60799

patchpack-bitmap: drop unused `reuse_objects`

Subject: [PATCH] pack-bitmap: drop unused `reuse_objects`

## tl;dr

2 messages between Jan 27, 2024 and Jan 29, 2024. Diffs are folded; open one to read it.

replies: 1people: 2as markdown or json

Taylor Blau· Jan 27, 2024, 04:00 UTC · lore

This variable is no longer used for doing verbatim pack-reuse (or anywhere within pack-bitmap.c) since d2ea031046 (pack-bitmap: don't rely on bitmap_git->reuse_objects, 2019-12-18).

Remove it to avoid an unused struct member.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
---
I noticed this while reading code in this area working on a new topic to
store "pseudo-merge" bitmaps, which can be used to accelerate bitmap
traversals when all commits in a given pseudo-merge appear on either
side of a traversal.
 pack-bitmap.c | 7 -------
 1 file changed, 7 deletions(-)
Show changes to pack-bitmap.c +0 −8
diff --git a/pack-bitmap.c b/pack-bitmap.c
index 229a11fb00..2baeabacee 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -51,13 +51,6 @@ struct bitmap_index {
 	struct packed_git *pack;
 	struct multi_pack_index *midx;

-	/*
-	 * Mark the first `reuse_objects` in the packfile as reused:
-	 * they will be sent as-is without using them for repacking
-	 * calculations
-	 */
-	uint32_t reuse_objects;
-
 	/* mmapped buffer of the whole bitmap index */
 	unsigned char *map;
 	size_t map_size; /* size of the mmaped buffer */
--
2.43.0.386.ge02ecfcc53.dirty
Jeff King· Jan 29, 2024, 18:14 UTC · re: Taylor Blau · lore

Re: [PATCH] pack-bitmap: drop unused `reuse_objects`

On Fri, Jan 26, 2024 at 11:00:50PM -0500, Taylor Blau wrote:
Show 5 quoted lines
> This variable is no longer used for doing verbatim pack-reuse (or
> anywhere within pack-bitmap.c) since d2ea031046 (pack-bitmap: don't rely
> on bitmap_git->reuse_objects, 2019-12-18).
> 
> Remove it to avoid an unused struct member.

Good catch. This has been sitting unused for quite some time. I wonder if there is a way to convince the compiler to tell us about unused struct fields. I guess that would imply a view of the whole linked program (though in this case the type is local to a single translation unit). And would probably produce a horrible number of false positives for structs defined in system headers.

Possibly static analyzers like coverity could help here, but it does not seem to find this case (or if it did, I could not find it amidst all of the false positives).

Anyway, your patch is obviously the right thing to do. :)
-Peff

← back to recent threads