From: Jeff King <peff@peff.net>
To: Sam James <sam@gentoo.org>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>, git@vger.kernel.org
Subject: [PATCH 4/5] object-file: drop oid field from find_cached_object() return value
Date: Sun, 17 Nov 2024 04:10:24 -0500 [thread overview]
Message-ID: <20241117091024.GD3409496@coredump.intra.peff.net> (raw)
In-Reply-To: <20241117090329.GA2341486@coredump.intra.peff.net>
The pretend_object_file() function adds to an array mapping oids to
object contents, which are later retrieved with find_cached_object().
We naturally need to store the oid for each entry, since it's the lookup
key.
But find_cached_object() also returns a hard-coded empty_tree object.
There we don't care about its oid field and instead compare against
the_hash_algo->empty_tree. The oid field is left as all-zeroes.
This all works, but it means that the cached_object struct we return
from find_cached_object() may or may not have a valid oid field, depend
whether it is the hard-coded tree or came from pretend_object_file().
Nobody looks at the field, so there's no bug. But let's future-proof it
by returning only the object contents themselves, not the oid. We'll
continue to call this "struct cached_object", and the array entry
mapping the key to those contents will be a "cached_object_entry".
This would also let us swap out the array for a better data structure
(like a hashmap) if we chose, but there's not much point. The only code
that adds an entry is git-blame, which adds at most a single entry per
process.
Signed-off-by: Jeff King <peff@peff.net>
---
object-file.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/object-file.c b/object-file.c
index 5fadd470c1..e461e351ca 100644
--- a/object-file.c
+++ b/object-file.c
@@ -317,27 +317,28 @@ int hash_algo_by_length(int len)
* to write them into the object store (e.g. a browse-only
* application).
*/
-static struct cached_object {
+static struct cached_object_entry {
struct object_id oid;
- enum object_type type;
- const void *buf;
- unsigned long size;
+ struct cached_object {
+ enum object_type type;
+ const void *buf;
+ unsigned long size;
+ } value;
} *cached_objects;
static int cached_object_nr, cached_object_alloc;
static struct cached_object *find_cached_object(const struct object_id *oid)
{
static struct cached_object empty_tree = {
- /* no oid needed; we'll look it up manually based on the_hash_algo */
.type = OBJ_TREE,
.buf = "",
};
int i;
- struct cached_object *co = cached_objects;
+ struct cached_object_entry *co = cached_objects;
for (i = 0; i < cached_object_nr; i++, co++) {
if (oideq(&co->oid, oid))
- return co;
+ return &co->value;
}
if (oideq(oid, the_hash_algo->empty_tree))
return &empty_tree;
@@ -1850,7 +1851,7 @@ int oid_object_info(struct repository *r,
int pretend_object_file(void *buf, unsigned long len, enum object_type type,
struct object_id *oid)
{
- struct cached_object *co;
+ struct cached_object_entry *co;
char *co_buf;
hash_object_file(the_hash_algo, buf, len, type, oid);
@@ -1859,11 +1860,11 @@ int pretend_object_file(void *buf, unsigned long len, enum object_type type,
return 0;
ALLOC_GROW(cached_objects, cached_object_nr + 1, cached_object_alloc);
co = &cached_objects[cached_object_nr++];
- co->size = len;
- co->type = type;
+ co->value.size = len;
+ co->value.type = type;
co_buf = xmalloc(len);
memcpy(co_buf, buf, len);
- co->buf = co_buf;
+ co->value.buf = co_buf;
oidcpy(&co->oid, oid);
return 0;
}
--
2.47.0.541.ge258d9a1f8
next prev parent reply other threads:[~2024-11-17 9:10 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-17 2:50 -Wunterminated-string-initialization warning with GCC 15 in object-file.c Sam James
2024-11-17 9:03 ` Jeff King
2024-11-17 9:08 ` [PATCH 1/5] object-file: prefer array-of-bytes initializer for hash literals Jeff King
2024-11-17 9:52 ` René Scharfe
2024-11-18 9:06 ` Jeff King
2024-11-17 9:08 ` [PATCH 2/5] object-file: drop confusing oid initializer of empty_tree struct Jeff King
2024-11-17 9:08 ` [PATCH 3/5] object-file: move empty_tree struct into find_cached_object() Jeff King
2024-11-18 7:40 ` Patrick Steinhardt
2024-11-18 9:17 ` Jeff King
2024-11-17 9:10 ` Jeff King [this message]
2024-11-17 9:14 ` [PATCH 5/5] object-file: inline empty tree and blob literals Jeff King
2024-11-18 7:40 ` Patrick Steinhardt
2024-11-17 16:03 ` -Wunterminated-string-initialization warning with GCC 15 in object-file.c brian m. carlson
2024-11-18 9:19 ` Jeff King
2024-11-18 9:58 ` Sam James
2024-11-18 7:40 ` Patrick Steinhardt
2024-11-18 9:54 ` [PATCH 0/6] -Wunterminated-string-initialization warning + cleanups Jeff King
2024-11-18 9:54 ` [PATCH 1/6] object-file: prefer array-of-bytes initializer for hash literals Jeff King
2024-11-18 9:55 ` [PATCH 2/6] object-file: drop confusing oid initializer of empty_tree struct Jeff King
2024-11-18 9:55 ` [PATCH 3/6] object-file: move empty_tree struct into find_cached_object() Jeff King
2024-11-18 9:55 ` [PATCH 4/6] object-file: drop oid field from find_cached_object() return value Jeff King
2024-11-18 9:55 ` [PATCH 5/6] object-file: treat cached_object values as const Jeff King
2024-11-18 9:55 ` [PATCH 6/6] object-file: inline empty tree and blob literals Jeff King
2024-11-18 10:51 ` [PATCH 0/6] -Wunterminated-string-initialization warning + cleanups Patrick Steinhardt
2024-11-18 12:49 ` Junio C Hamano
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=20241117091024.GD3409496@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=sam@gentoo.org \
--cc=sandals@crustytoothpaste.net \
/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