I often get confused about the difference between:
- read_object()
- read_object_file();
- read_object_file_extended();
- repo_read_object_file();
Since Jonathan's recent cleanups from 9e59b38c88 (object-file: emit
corruption errors when detected, 2022-12-14), these are mostly thin
wrappers around each other and around oid_object_info_extended().
This series shuffles things around a little more so that we are down to
just read_object_file() and repo_read_object_file(). And the
relationship there is pretty easy (and long-term we'd eventually merge
them once everyone has a repository object).
It is a net reduction in lines, even though some of the callers end up a
little longer (because they have to stuff pointers into an object_info
struct). If that's too distasteful, the middle ground is to have a
helper like:
void *foo(struct repository *r, const struct object_id *oid,
enum object_type *type, unsigned long *size,
unsigned flags)
{
struct object_info oi = OBJECT_INFO_INIT;
void *content;
oi.typep = type;
oi.sizep = size;
oi.contentp = ret;
if (oid_object_info_extended(r, oid, &oi, flags) < 0)
return NULL;
return content;
}
which is basically the same as read_object(), but makes it clear that
you can pass OBJECT_INFO flags. The trouble is that I could not come up
with a name for it that was not confusing. ;) So just having most places
call oid_object_info_extended() directly seemed better. It would be nice
if that function had a shorter name, too, but I left that for another
day.
[1/5]: object-file: inline calls to read_object()
[2/5]: streaming: inline call to read_object_file_extended()
[3/5]: read_object_file_extended(): drop lookup_replace option
[4/5]: repo_read_object_file(): stop wrapping read_object_file_extended()
[5/5]: packfile: inline custom read_object()
object-file.c | 52 ++++++++++++++++++--------------------------------
object-store.h | 18 +++++------------
packfile.c | 26 +++++++++----------------
streaming.c | 11 ++++++++---
4 files changed, 41 insertions(+), 66 deletions(-)
-Peff
