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

Re: [PATCH 02/16] refs: rename `init_db` callback to avoid confusion

From
Junio C Hamano <gitster@pobox.com>
Date
May 16, 2024, 18:24 UTC
Message-ID
<xmqqa5kpr4wr.fsf@gitster.g>
In-Reply-To
<3cc2b4e5501ebe1464a6d75b7aea9f2ad6030c4a.1715836916.git.ps@pks.im>
Patrick Steinhardt <ps@pks.im> writes:
Show 7 quoted lines
> Reference backends have two callbacks `init` and `init_db`. The
> similarity of these two callbacks has repeatedly tripped myself whenever
> I was looking at those, where I always had to look up which of them does
> what.
>
> Rename the `init_db` callback to `create`, which should hopefully be
> clearer.

Hmph, create() may be clearer than init_db(), but then I am not sure what init() would do, differently from create(), so this rename takes me back to the puzzled square one state X-<.

I am guessing that create is about creating on-disk structure, while init is about in-core structure out of an existing on-disk structure? Once I understand the differences in these two things, it is much less troublesome to tell them apart, regardless of what they are called. Between .init and .init_db, it would be obvious that the latter is about on-disk thing, without a rename done by this step. On the other hand, contrast between <create, init> is just as opaque as <init_db, init>---the names do not tell readers that these two are about on-disk and in-core structures.

Just my confused impression.
Previous: Karthik NayakNext: Patrick Steinhardt
Message 6 of 33 in “refs: drop all references to `the_repository`”
  1. 00/16 refs: drop all references to `the_repository`Patrick Steinhardt, May 16, 2024
  2. 01/16 refs: adjust names for `init` and `init_db` callbacksPatrick Steinhardt, May 16, 2024
  3. Karthik NayakMay 16, 2024
  4. 02/16 refs: rename `init_db` callback to avoid confusionPatrick Steinhardt, May 16, 2024
  5. Karthik NayakMay 16, 2024
  6. Junio C HamanoMay 16, 2024
  7. Patrick SteinhardtMay 17, 2024
  8. 03/16 refs: implement releasing ref storagesPatrick Steinhardt, May 16, 2024
  9. Karthik NayakMay 16, 2024
  10. Junio C HamanoMay 16, 2024
  11. Patrick SteinhardtMay 17, 2024
  12. Patrick SteinhardtMay 17, 2024
  13. 04/16 refs: track ref stores via strmapPatrick Steinhardt, May 16, 2024
  14. Junio C HamanoMay 16, 2024
  15. 05/16 refs: pass repo when retrieving submodule ref storePatrick Steinhardt, May 16, 2024
  16. Junio C HamanoMay 16, 2024
  17. Patrick SteinhardtMay 17, 2024
  18. 06/16 refs: refactor `resolve_gitlink_ref()` to accept a repositoryPatrick Steinhardt, May 16, 2024
  19. Junio C HamanoMay 16, 2024
  20. 07/16 refs: retrieve worktree ref stores via associated repositoryPatrick Steinhardt, May 16, 2024
  21. 08/16 refs: convert iteration over replace refs to accept ref storePatrick Steinhardt, May 16, 2024
  22. 09/16 refs: pass ref store when detecting dangling symrefsPatrick Steinhardt, May 16, 2024
  23. 10/16 refs: move object peeling into "object.c"Patrick Steinhardt, May 16, 2024
  24. Junio C HamanoMay 16, 2024
  25. 11/16 refs: pass repo when peeling objectsPatrick Steinhardt, May 16, 2024
  26. 12/16 refs: drop `git_default_branch_name()`Patrick Steinhardt, May 16, 2024
  27. Karthik NayakMay 16, 2024
  28. 13/16 refs: remove `dwim_log()`Patrick Steinhardt, May 16, 2024
  29. 14/16 refs/files: use correct repositoryPatrick Steinhardt, May 16, 2024
  30. 15/16 refs/files: remove references to `the_hash_algo`Patrick Steinhardt, May 16, 2024
  31. 16/16 refs/packed: remove references to `the_hash_algo`Patrick Steinhardt, May 16, 2024
  32. Karthik NayakMay 16, 2024
  33. Patrick SteinhardtMay 17, 2024

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.