From: Junio C Hamano <gitster@pobox•com>
To: Ronnie Sahlberg <sahlberg@google•com>
Cc: git@vger•kernel.org
Subject: Re: [PATCH v3 19/23] refs-be-files.c: add a backend method structure with transaction functions
Date: Tue, 26 Aug 2014 14:38:42 -0700 [thread overview]
Message-ID: <xmqq8umbgcd9.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1408465847-30384-20-git-send-email-sahlberg@google.com> (Ronnie Sahlberg's message of "Tue, 19 Aug 2014 09:30:43 -0700")
Ronnie Sahlberg <sahlberg@google•com> writes:
> diff --git a/refs-be-files.c b/refs-be-files.c
> index e58a7e1..27eafd0 100644
> --- a/refs-be-files.c
> +++ b/refs-be-files.c
> ...
> +struct ref_be refs_files = {
> + files_transaction_begin,
> + files_transaction_update_sha1,
> + files_transaction_create_sha1,
> + files_transaction_delete_sha1,
> + files_transaction_update_reflog,
> + files_transaction_commit,
> + files_transaction_free,
> +};
> +
> +struct ref_be *refs = &refs_files;
> diff --git a/refs.c b/refs.c
> index 6b434ad..b8c942f 100644
> --- a/refs.c
> +++ b/refs.c
> ...
> +void transaction_free(struct ref_transaction *transaction)
> +{
> + return refs->transaction_free(transaction);
> +}
> diff --git a/refs.h b/refs.h
> index a14fc5d..4b669f5 100644
> --- a/refs.h
> +++ b/refs.h
> ...
> +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;
> +
> #endif /* REFS_H */
The overall structure is certainly nice, but this means you only can
LINK with one backend. Is that what we really want?
I would have expected something like this:
* In refs.c, there is a "static struct ref_be *the_refs_backend"
that points at the chosen singleton backend;
* Upon start-up, set_refs_backend() function that is exported from
refs.c can be used to set the_refs_backend;
* Each refs-be-frotz.c will export "struct ref_be refs_frotz" (or
perhaps "struct refs_be refs_be_frotz") to the outside world, so
that the start-up code can call set_refs_backend() with it.
* It is probably sensible to keep the_refs_backend default to
&refs_be_files.
next prev parent reply other threads:[~2014-08-26 21:38 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-19 16:30 [PATCH v3 00/23] backend-struct-db Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 01/23] refs.c: create a public function for is_refname_available Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 03/23] refs.c: add a new refs.c file to hold all common refs code Ronnie Sahlberg
2014-08-26 21:31 ` Junio C Hamano
2014-08-26 22:00 ` Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 04/23] refs.c: move update_ref to refs.c Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 05/23] refs.c: move delete_ref to the common code Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 06/23] refs.c: move rename_ref " Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 07/23] refs.c: move read_ref_at to the common refs file Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 08/23] refs.c: move the hidden refs functions to the common code Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 09/23] refs.c: move dwim and friend functions to the common refs code Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 10/23] refs.c: move warn_if_dangling_symref* to the common code Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 11/23] refs.c: move read_ref, read_ref_full and ref_exists " Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 12/23] refs.c: move resolve_refdup to common Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 13/23] refs.c: move check_refname_component to the common code Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 14/23] refs.c: move is_branch " Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 15/23] refs.c: move names_conflict " Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 16/23] refs.c: move prettify_refname " Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 17/23] refs.c: move ref iterators " Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 18/23] refs.c: move head_ref_namespaced " Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 19/23] refs-be-files.c: add a backend method structure with transaction functions Ronnie Sahlberg
2014-08-26 21:38 ` Junio C Hamano [this message]
2014-08-26 22:34 ` Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 20/23] refs-be-files.c: add reflog backend methods Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 21/23] refs-be-files.c: add methods for misc ref operations Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 22/23] refs-be-files.c: add methods for head_ref* Ronnie Sahlberg
2014-08-19 16:30 ` [PATCH v3 23/23] refs-be-files.c: add methods for the ref iterators Ronnie Sahlberg
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=xmqq8umbgcd9.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=sahlberg@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox