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

Re: [PATCH v2 18/23] refs.c: add a backend method structure with transaction functions

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 26, 2014, 21:25 UTC
Message-ID
<xmqqha0zgcym.fsf@gitster.dls.corp.google.com>
In-Reply-To
<1407960907-18189-19-git-send-email-sahlberg@google.com>
Ronnie Sahlberg <sahlberg@google.com> writes:
Show 11 quoted lines
> +struct ref_be {
> +	transaction_begin_fn transaction_begin;
> +	transaction_update_sha1_fn transaction_update_sha1;
> +	transaction_create_sha1_fn transaction_create_sha1;
> +	transaction_delete_sha1_fn transaction_delete_sha1;
> +	transaction_update_reflog_fn transaction_update_reflog;
> +	transaction_commit_fn transaction_commit;
> +	transaction_free_fn transaction_free;
> +};
> +
> +extern struct ref_be *refs;

The overall organization is nice, but please don't use such a short name for the systemwide default singleton instance, which should not be accessed by normal code other than via helpers that implicitly use that singleton (e.g. resolve_ref_unsafe() which invokes the method of the same name on the singleton, passing the parameters it received[*1*]). The name will be used for other things (e.g. a local variable for a collection of refs) by code that do not care about the underlying implementation of the helpers and will cause confusion later.

Perhaps the_refs_backend or something?

Also does the singleton have to be extern, not a static inside refs.c, perhaps with a setter function to switch it or something?

[Reference]
*1* A typical helper that uses the singleton looks like this:

+const char *resolve_ref_unsafe(const char *ref, unsigned char *sha1, + int reading, int *flag) +{ + return refs->resolve_ref_unsafe(ref, sha1, reading, flag); +}

Previous: Ronnie SahlbergNext: Ronnie Sahlberg
Message 20 of 27 in “backend-struct-db”
  1. 00/23 backend-struct-dbRonnie Sahlberg, Aug 13, 2014
  2. 01/23 refs.c: create a public function for is_refname_availableRonnie Sahlberg, Aug 13, 2014
  3. 02/23 refs-common.c: create a file to host all common refs codeRonnie Sahlberg, Aug 13, 2014
  4. 03/23 refs-common.c: move update_ref to refs-common.cRonnie Sahlberg, Aug 13, 2014
  5. 04/23 refs-common.c: move delete_ref to the common codeRonnie Sahlberg, Aug 13, 2014
  6. 05/23 refs-common.c: move rename_ref to the common codeRonnie Sahlberg, Aug 13, 2014
  7. 06/23 refs-common.c: move read_ref_at to the refs common fileRonnie Sahlberg, Aug 13, 2014
  8. 07/23 refs-common.c: move the hidden refs functions to the common codeRonnie Sahlberg, Aug 13, 2014
  9. 08/23 refs-common.c: move dwim and friend functions to refs commonRonnie Sahlberg, Aug 13, 2014
  10. 09/23 refs-common.c: move warn_if_dangling_symref* to refs-commonRonnie Sahlberg, Aug 13, 2014
  11. 10/23 refs-common.c: move read_ref, read_ref_full and ref_exists to commonRonnie Sahlberg, Aug 13, 2014
  12. 11/23 refs-common.c: move resolve_refdup to commonRonnie Sahlberg, Aug 13, 2014
  13. 12/23 refs-common.c: move check_refname_component to the common codeRonnie Sahlberg, Aug 13, 2014
  14. 13/23 refs-common.c: move is_branch to the common codeRonnie Sahlberg, Aug 13, 2014
  15. 14/23 refs-common.c: move names_conflict to the common codeRonnie Sahlberg, Aug 13, 2014
  16. 15/23 refs-common.c: move prettify_refname to the common codeRonnie Sahlberg, Aug 13, 2014
  17. 16/23 refs-common.c: move ref iterators to the common codeRonnie Sahlberg, Aug 13, 2014
  18. 17/23 refs-common.c: move head_ref_namespaced to the common fileRonnie Sahlberg, Aug 13, 2014
  19. 18/23 refs.c: add a backend method structure with transaction functionsRonnie Sahlberg, Aug 13, 2014
  20. Junio C HamanoAug 26, 2014
  21. Ronnie SahlbergAug 26, 2014
  22. 19/23 refs.c: add reflog backend methodsRonnie Sahlberg, Aug 13, 2014
  23. 20/23 refs.c: add methods for misc ref operationsRonnie Sahlberg, Aug 13, 2014
  24. 21/23 refs.c: add methods for head_ref*Ronnie Sahlberg, Aug 13, 2014
  25. 22/23 refs.c: add methods for the ref iteratorsRonnie Sahlberg, Aug 13, 2014
  26. Junio C HamanoAug 13, 2014
  27. Ronnie SahlbergAug 13, 2014

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.