From: Patrick Steinhardt <ps@pks.im>
To: git@vger.kernel.org
Cc: Elijah Newren <newren@gmail.com>,
Eric Sunshine <sunshine@sunshineco.com>,
Jeff King <peff@peff.net>, Junio C Hamano <gitster@pobox.com>
Subject: [PATCH v3 09/10] object-store: remove global array of cached objects
Date: Tue, 15 Apr 2025 11:38:22 +0200 [thread overview]
Message-ID: <20250415-pks-split-object-file-v3-9-6aa7db7ad7b0@pks.im> (raw)
In-Reply-To: <20250415-pks-split-object-file-v3-0-6aa7db7ad7b0@pks.im>
Cached objects are virtual objects that can be set up without writing
anything into the object store directly, which is used by git-blame(1)
to create fake commits for the working tree.
These cached objects are stored in a global variable, which is another
roadblock for libification of the object subsystem. Refactor the code so
that we instead store the array as part of the raw object store.
This refactoring raises the question whether virtual objects should
really be specific to a single repository (or rather a single object
store). Hypothetical usecases might for example span across submodules,
and here it may or may not be the right thing to provide virtual objects
across submodule boundaries.
The only existing usecase is git-blame(1) though, which does not know to
blame across submodule boundaries in the first place. As such, storing
these objects both globally and per-repository would achieve the same
result right now. But arguably, if we learned to blame across submodule
boundaries, we would likely want to create separate fare working tree
commits for each of the submodules so that the user can learn which
worktree a specific uncommitted change belongs to. And even if we would
want to create the same fake commit for each of the submodules we could
do that when storing separate virtual objects per object store.
While this is all rather hypothetical, the takeaway is that handling
virtual objects per-object store gives us more flexibility compared to
storing them globally. In a hypothetical future where we have achieved
full libification one might be able to handle unrelated repositories in
a single process, where the state of one repository should not have an
impact on the state of another repository. As such, storing these cached
objects per object store will enable more usecases and should lead to
less surprising outcomes overall.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
blame.c | 2 +-
object-store-ll.h | 14 +++++++++++++-
object-store.c | 39 +++++++++++++++++++++++----------------
3 files changed, 37 insertions(+), 18 deletions(-)
diff --git a/blame.c b/blame.c
index 703dab43e78..b7c5bd692e6 100644
--- a/blame.c
+++ b/blame.c
@@ -277,7 +277,7 @@ static struct commit *fake_working_tree_commit(struct repository *r,
convert_to_git(r->index, path, buf.buf, buf.len, &buf, 0);
origin->file.ptr = buf.buf;
origin->file.size = buf.len;
- pretend_object_file(buf.buf, buf.len, OBJ_BLOB, &origin->blob_oid);
+ pretend_object_file(the_repository, buf.buf, buf.len, OBJ_BLOB, &origin->blob_oid);
/*
* Read the current index, replace the path entry with
diff --git a/object-store-ll.h b/object-store-ll.h
index 8bb0f33f9a8..bb5e8798a1b 100644
--- a/object-store-ll.h
+++ b/object-store-ll.h
@@ -151,6 +151,8 @@ static inline int pack_map_entry_cmp(const void *cmp_data UNUSED,
return strcmp(pg1->pack_name, key ? key : pg2->pack_name);
}
+struct cached_object_entry;
+
struct raw_object_store {
/*
* Set of all object directories; the main directory is first (and
@@ -203,6 +205,15 @@ struct raw_object_store {
unsigned flags;
} kept_pack_cache;
+ /*
+ * This is meant to hold a *small* number of objects that you would
+ * want repo_read_object_file() to be able to return, but yet you do not want
+ * to write them into the object store (e.g. a browse-only
+ * application).
+ */
+ struct cached_object_entry *cached_objects;
+ size_t cached_object_nr, cached_object_alloc;
+
/*
* A map of packfiles to packed_git structs for tracking which
* packs have been loaded already.
@@ -272,7 +283,8 @@ void hash_object_file(const struct git_hash_algo *algo, const void *buf,
* object in persistent storage before writing any other new objects
* that reference it.
*/
-int pretend_object_file(void *, unsigned long, enum object_type,
+int pretend_object_file(struct repository *repo,
+ void *buf, unsigned long len, enum object_type type,
struct object_id *oid);
struct object_info {
diff --git a/object-store.c b/object-store.c
index 896d9ac3509..0f1dcc113ed 100644
--- a/object-store.c
+++ b/object-store.c
@@ -30,31 +30,31 @@
* to write them into the object store (e.g. a browse-only
* application).
*/
-static struct cached_object_entry {
+struct cached_object_entry {
struct object_id oid;
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 const struct cached_object *find_cached_object(const struct object_id *oid)
+static const struct cached_object *find_cached_object(struct raw_object_store *object_store,
+ const struct object_id *oid)
{
static const struct cached_object empty_tree = {
.type = OBJ_TREE,
.buf = "",
};
- int i;
- const struct cached_object_entry *co = cached_objects;
+ const struct cached_object_entry *co = object_store->cached_objects;
- for (i = 0; i < cached_object_nr; i++, co++) {
+ for (size_t i = 0; i < object_store->cached_object_nr; i++, co++)
if (oideq(&co->oid, oid))
return &co->value;
- }
- if (oideq(oid, the_hash_algo->empty_tree))
+
+ if (oid->algo && oideq(oid, hash_algos[oid->algo].empty_tree))
return &empty_tree;
+
return NULL;
}
@@ -650,7 +650,7 @@ static int do_oid_object_info_extended(struct repository *r,
if (!oi)
oi = &blank_oi;
- co = find_cached_object(real);
+ co = find_cached_object(r->objects, real);
if (co) {
if (oi->typep)
*(oi->typep) = co->type;
@@ -853,18 +853,21 @@ int oid_object_info(struct repository *r,
return type;
}
-int pretend_object_file(void *buf, unsigned long len, enum object_type type,
+int pretend_object_file(struct repository *repo,
+ void *buf, unsigned long len, enum object_type type,
struct object_id *oid)
{
struct cached_object_entry *co;
char *co_buf;
- hash_object_file(the_hash_algo, buf, len, type, oid);
- if (repo_has_object_file_with_flags(the_repository, oid, OBJECT_INFO_QUICK | OBJECT_INFO_SKIP_FETCH_OBJECT) ||
- find_cached_object(oid))
+ hash_object_file(repo->hash_algo, buf, len, type, oid);
+ if (repo_has_object_file_with_flags(repo, oid, OBJECT_INFO_QUICK | OBJECT_INFO_SKIP_FETCH_OBJECT) ||
+ find_cached_object(repo->objects, oid))
return 0;
- ALLOC_GROW(cached_objects, cached_object_nr + 1, cached_object_alloc);
- co = &cached_objects[cached_object_nr++];
+
+ ALLOC_GROW(repo->objects->cached_objects,
+ repo->objects->cached_object_nr + 1, repo->objects->cached_object_alloc);
+ co = &repo->objects->cached_objects[repo->objects->cached_object_nr++];
co->value.size = len;
co->value.type = type;
co_buf = xmalloc(len);
@@ -1021,6 +1024,10 @@ void raw_object_store_clear(struct raw_object_store *o)
o->odb_tail = NULL;
o->loaded_alternates = 0;
+ for (size_t i = 0; i < o->cached_object_nr; i++)
+ free((char *) o->cached_objects[i].value.buf);
+ FREE_AND_NULL(o->cached_objects);
+
INIT_LIST_HEAD(&o->packed_git_mru);
close_object_store(o);
--
2.49.0.805.g082f7c87e0.dirty
next prev parent reply other threads:[~2025-04-15 9:38 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 10:24 [PATCH 0/9] Split up "object-file.c" Patrick Steinhardt
2025-04-08 10:24 ` [PATCH 1/9] object-file: move `safe_create_leading_directories()` into "dir.c" Patrick Steinhardt
2025-04-09 14:36 ` Elijah Newren
2025-04-11 9:27 ` Patrick Steinhardt
2025-04-11 17:11 ` Elijah Newren
2025-04-15 9:19 ` Patrick Steinhardt
2025-04-15 15:11 ` Junio C Hamano
2025-04-08 10:24 ` [PATCH 2/9] object-file: move `git_open_cloexec()` to "compat/open.c" Patrick Steinhardt
2025-04-08 10:24 ` [PATCH 3/9] object-file: move `xmmap()` into "wrapper.c" Patrick Steinhardt
2025-04-09 14:36 ` Elijah Newren
2025-04-08 10:24 ` [PATCH 4/9] object-file: split out functions relating to object store subsystem Patrick Steinhardt
2025-04-08 10:24 ` [PATCH 5/9] object-file: split up concerns of `HASH_*` flags Patrick Steinhardt
2025-04-08 10:24 ` [PATCH 6/9] object-file: split out functions relating to index subsystem Patrick Steinhardt
2025-04-08 10:24 ` [PATCH 7/9] object: split out functions relating to object store subsystem Patrick Steinhardt
2025-04-08 10:24 ` [PATCH 8/9] object-store: remove global array of cached objects Patrick Steinhardt
2025-04-08 10:24 ` [PATCH 9/9] object-store: merge "object-store-ll.h" and "object-store.h" Patrick Steinhardt
2025-04-08 23:29 ` [PATCH 0/9] Split up "object-file.c" Junio C Hamano
2025-04-11 9:26 ` Patrick Steinhardt
2025-04-09 14:42 ` Elijah Newren
2025-04-11 9:27 ` Patrick Steinhardt
2025-04-11 9:29 ` [PATCH v2 " Patrick Steinhardt
2025-04-11 9:29 ` [PATCH v2 1/9] object-file: move `safe_create_leading_directories()` into "dir.c" Patrick Steinhardt
2025-04-11 20:09 ` Junio C Hamano
2025-04-11 21:29 ` Eric Sunshine
2025-04-15 9:19 ` Patrick Steinhardt
2025-04-15 15:09 ` Junio C Hamano
2025-04-11 9:29 ` [PATCH v2 2/9] object-file: move `git_open_cloexec()` to "compat/open.c" Patrick Steinhardt
2025-04-11 9:29 ` [PATCH v2 3/9] object-file: move `xmmap()` into "wrapper.c" Patrick Steinhardt
2025-04-11 9:29 ` [PATCH v2 4/9] object-file: split out functions relating to object store subsystem Patrick Steinhardt
2025-04-11 9:29 ` [PATCH v2 5/9] object-file: split up concerns of `HASH_*` flags Patrick Steinhardt
2025-04-11 9:29 ` [PATCH v2 6/9] object-file: split out functions relating to index subsystem Patrick Steinhardt
2025-04-12 8:17 ` Jeff King
2025-04-14 11:49 ` Junio C Hamano
2025-04-15 9:19 ` Patrick Steinhardt
2025-04-11 9:29 ` [PATCH v2 7/9] object: split out functions relating to object store subsystem Patrick Steinhardt
2025-04-11 9:29 ` [PATCH v2 8/9] object-store: remove global array of cached objects Patrick Steinhardt
2025-04-11 22:58 ` Junio C Hamano
2025-04-15 9:19 ` Patrick Steinhardt
2025-04-11 9:29 ` [PATCH v2 9/9] object-store: merge "object-store-ll.h" and "object-store.h" Patrick Steinhardt
2025-04-15 9:38 ` [PATCH v3 00/10] Split up "object-file.c" Patrick Steinhardt
2025-04-15 9:38 ` [PATCH v3 01/10] object-file: move `mkdir_in_gitdir()` into "path.c" Patrick Steinhardt
2025-04-15 9:38 ` [PATCH v3 02/10] object-file: move `safe_create_leading_directories()` " Patrick Steinhardt
2025-04-15 9:38 ` [PATCH v3 03/10] object-file: move `git_open_cloexec()` to "compat/open.c" Patrick Steinhardt
2025-04-15 9:38 ` [PATCH v3 04/10] object-file: move `xmmap()` into "wrapper.c" Patrick Steinhardt
2025-04-15 9:38 ` [PATCH v3 05/10] object-file: split out functions relating to object store subsystem Patrick Steinhardt
2025-04-15 9:38 ` [PATCH v3 06/10] object-file: split up concerns of `HASH_*` flags Patrick Steinhardt
2025-04-15 9:38 ` [PATCH v3 07/10] object-file: drop `index_blob_stream()` Patrick Steinhardt
2025-04-15 9:38 ` [PATCH v3 08/10] object: split out functions relating to object store subsystem Patrick Steinhardt
2025-04-15 9:38 ` Patrick Steinhardt [this message]
2025-04-15 9:38 ` [PATCH v3 10/10] object-store: merge "object-store-ll.h" and "object-store.h" Patrick Steinhardt
2025-04-16 6:41 ` [PATCH v3 00/10] Split up "object-file.c" Elijah Newren
2025-04-16 7:44 ` Patrick Steinhardt
2025-04-16 16:21 ` 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=20250415-pks-split-object-file-v3-9-6aa7db7ad7b0@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
--cc=peff@peff.net \
--cc=sunshine@sunshineco.com \
/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;
as well as URLs for NNTP newsgroup(s).