git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Jan 7, 2023, 13:48 UTC
Message-ID
<Y7l4LsEQcDT9HZ21@coredump.intra.peff.net>
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
Next: Jeff King
Message 1 of 20 in “cleaning up read_object() family of functions”
  1. 0/5 cleaning up read_object() family of functionsJeff King, Jan 7, 2023
  2. 1/5 object-file: inline calls to read_object()Jeff King, Jan 7, 2023
  3. Ævar Arnfjörð BjarmasonJan 12, 2023
  4. object-file: fix indent-with-spaceJeff King, Jan 12, 2023
  5. Ævar Arnfjörð BjarmasonJan 12, 2023
  6. Junio C HamanoJan 13, 2023
  7. 2/5 streaming: inline call to read_object_file_extended()Jeff King, Jan 7, 2023
  8. 3/5 read_object_file_extended(): drop lookup_replace optionJeff King, Jan 7, 2023
  9. 4/5 repo_read_object_file(): stop wrapping read_object_file_extended()Jeff King, Jan 7, 2023
  10. 5/5 packfile: inline custom read_object()Jeff King, Jan 7, 2023
  11. Ævar Arnfjörð BjarmasonJan 12, 2023
  12. Jeff KingJan 12, 2023
  13. Derrick StoleeJan 9, 2023
  14. Jeff KingJan 11, 2023
  15. Derrick StoleeJan 11, 2023
  16. Jeff KingJan 11, 2023
  17. Ævar Arnfjörð BjarmasonJan 12, 2023
  18. Jeff KingJan 12, 2023
  19. Ævar Arnfjörð BjarmasonJan 12, 2023
  20. Jeff KingJan 12, 2023

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.