Patrick Steinhardt [off-list ref] writes:
quoted hunk ↗ jump to hunk
In `has_object_pack()` we're checking whether a specific object exists
as part of a packfile. This is done by calling the low-level function
`find_pack_entry()`, but this function will eventually be moved into
"odb/source-packed.c" and made file-local.
Refactor the code to use `packfile_store_read_object_info()` instead.
This refactoring is functionally equivalent as that function will call
`find_pack_entry()` itself and then return immediately when it ain't got
no object info pointer as parameter.
Signed-off-by: Patrick Steinhardt <redacted>
---
packfile.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/packfile.c b/packfile.c
index 902b7f70f2..3ee71d7f71 100644
--- a/packfile.c
+++ b/packfile.c
@@ -2132,14 +2132,12 @@ struct packed_git **packfile_store_get_kept_pack_cache(struct odb_source_packed
int has_object_pack(struct repository *r, const struct object_id *oid)
{
struct odb_source *source;
- struct pack_entry e;
odb_prepare_alternates(r->objects);
for (source = r->objects->sources; source; source = source->next) {
struct odb_source_files *files = odb_source_files_downcast(source);
- int ret = find_pack_entry(files->packed, oid, &e);
- if (ret)
- return ret;
+ if (!packfile_store_read_object_info(files->packed, oid, NULL, 0))
+ return 1;
}
I was wondering if there would be an added cost of actually obtaining
the object-info. Seems like there isn't, because we pass `NULL` for the
`struct object_info *oi`, which means it will return before reading the
object info.
return 0;
--
2.54.0.1064.gd145956f57.dirty