All of lore.kernel.org
 help / color / mirror / Atom feed
From: Derrick Stolee <derrickstolee@github.com>
To: Jeff King <peff@peff.net>, git@vger.kernel.org
Cc: Jonathan Tan <jonathantanmy@google.com>
Subject: Re: [PATCH 0/5] cleaning up read_object() family of functions
Date: Mon, 9 Jan 2023 10:09:32 -0500	[thread overview]
Message-ID: <f1028cba-5fc6-3584-3f21-545550012e9d@github.com> (raw)
In-Reply-To: <Y7l4LsEQcDT9HZ21@coredump.intra.peff.net>

On 1/7/2023 8:48 AM, Jeff King wrote:
> 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).

I read the patches carefully and the translations look correct and
definitely help with this confusing mess of method names.

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

I did think that requiring callers to create their own object_info
structs (which takes at least four lines) would be too much, but
the number of new callers is so low that I think this is a fine place
to stop.

Thanks,
-Stolee

  parent reply	other threads:[~2023-01-09 15:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-07 13:48 [PATCH 0/5] cleaning up read_object() family of functions Jeff King
2023-01-07 13:48 ` [PATCH 1/5] object-file: inline calls to read_object() Jeff King
2023-01-12  9:13   ` Ævar Arnfjörð Bjarmason
2023-01-12 16:06     ` [PATCH] object-file: fix indent-with-space Jeff King
2023-01-12 16:08       ` Ævar Arnfjörð Bjarmason
2023-01-13 17:40         ` Junio C Hamano
2023-01-07 13:49 ` [PATCH 2/5] streaming: inline call to read_object_file_extended() Jeff King
2023-01-07 13:50 ` [PATCH 3/5] read_object_file_extended(): drop lookup_replace option Jeff King
2023-01-07 13:50 ` [PATCH 4/5] repo_read_object_file(): stop wrapping read_object_file_extended() Jeff King
2023-01-07 13:50 ` [PATCH 5/5] packfile: inline custom read_object() Jeff King
2023-01-12  9:01   ` Ævar Arnfjörð Bjarmason
2023-01-12 16:29     ` Jeff King
2023-01-09 15:09 ` Derrick Stolee [this message]
2023-01-11 18:26   ` [PATCH 0/5] cleaning up read_object() family of functions Jeff King
2023-01-11 20:17     ` Derrick Stolee
2023-01-11 20:30       ` Jeff King
2023-01-12  9:21     ` Ævar Arnfjörð Bjarmason
2023-01-12 16:16       ` Jeff King
2023-01-12 16:22         ` Ævar Arnfjörð Bjarmason
2023-01-12 16:53           ` Jeff King

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=f1028cba-5fc6-3584-3f21-545550012e9d@github.com \
    --to=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.com \
    --cc=peff@peff.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.