Re: [PATCH 0/5] cleaning up read_object() family of functions

> 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.