From: David Turner <dturner@twopensource.com>
To: Michael Haggerty <mhagger@alum.mit.edu>, git@vger.kernel.org
Subject: Re: [PATCH v4 14/21] refs: always handle non-normal refs in files backend
Date: Wed, 17 Feb 2016 21:44:00 -0500 [thread overview]
Message-ID: <1455763440.7528.71.camel@twopensource.com> (raw)
In-Reply-To: <56BDF531.7010909@alum.mit.edu>
On Fri, 2016-02-12 at 16:07 +0100, Michael Haggerty wrote:
> On 02/05/2016 08:44 PM, David Turner wrote:
> > Always handle non-normal (per-worktree or pseudo) refs in the files
> > backend instead of alternate backends.
> >
> > Sometimes a ref transaction will update both a per-worktree ref and
> > a
> > normal ref. For instance, an ordinary commit might update
> > refs/heads/master and HEAD (or at least HEAD's reflog).
> >
> > Updates to normal refs continue to go through the chosen backend.
> >
> > Updates to non-normal refs are moved to a separate files backend
> > transaction.
> >
> > Signed-off-by: David Turner <dturner@twopensource.com>
> > ---
> > refs.c | 81
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 79 insertions(+), 2 deletions(-)
> >
> > diff --git a/refs.c b/refs.c
> > index 227c018..18ba356 100644
> > --- a/refs.c
> > +++ b/refs.c
> > @@ -9,6 +9,11 @@
> > #include "object.h"
> > #include "tag.h"
> >
> > +static const char split_transaction_fail_warning[] = N_(
> > + "A ref transaction was split across two refs backends.
> > Part of the "
> > + "transaction succeeded, but then the update to the per
> > -worktree refs "
> > + "failed. Your repository may be in an inconsistent
> > state.");
> > +
> > /*
> > * We always have a files backend and it is the default.
> > */
> > @@ -791,6 +796,13 @@ void ref_transaction_free(struct
> > ref_transaction *transaction)
> > free(transaction);
> > }
> >
> > +static void add_update_obj(struct ref_transaction *transaction,
> > + struct ref_update *update)
> > +{
> > + ALLOC_GROW(transaction->updates, transaction->nr + 1,
> > transaction->alloc);
> > + transaction->updates[transaction->nr++] = update;
> > +}
> > +
> > static struct ref_update *add_update(struct ref_transaction
> > *transaction,
> > const char *refname)
> > {
> > @@ -798,8 +810,7 @@ static struct ref_update *add_update(struct
> > ref_transaction *transaction,
> > struct ref_update *update = xcalloc(1, sizeof(*update) +
> > len);
> >
> > memcpy((char *)update->refname, refname, len); /* includes
> > NUL */
> > - ALLOC_GROW(transaction->updates, transaction->nr + 1,
> > transaction->alloc);
> > - transaction->updates[transaction->nr++] = update;
> > + add_update_obj(transaction, update);
> > return update;
> > }
> >
> > @@ -1217,11 +1228,38 @@ static int dereference_symrefs(struct
> > ref_transaction *transaction,
> > return 0;
> > }
> >
> > +/*
> > + * Move all non-normal ref updates into a specially-created
> > + * files-backend transaction
> > + */
> > +static int move_abnormal_ref_updates(struct ref_transaction
> > *transaction,
> > + struct ref_transaction
> > *files_transaction,
> > + struct strbuf *err)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < transaction->nr; i++) {
> > + int last;
> > + struct ref_update *update = transaction
> > ->updates[i];
> > +
> > + if (ref_type(update->refname) == REF_TYPE_NORMAL)
> > + continue;
> > +
> > + last = --transaction->nr;
> > + transaction->updates[i] = transaction
> > ->updates[last];
> > + add_update_obj(files_transaction, update);
> > + }
> > +
> > + return 0;
> > +}
> > +
>
> I think this function is incorrect. The update that was previously at
> transaction->updates[i] never gets checked for abnormality.
Yes it does; that's the "update" variable that we just checked.
> You could
> fix that and also avoid gratuitously changing the order of the
> updates
> like this:
>
> static int move_abnormal_ref_updates(struct ref_transaction
> *transaction,
> struct ref_transaction
> *files_transaction,
> struct strbuf *err)
> {
> int i, normal_nr = 0;
>
> for (i = 0; i < transaction->nr; i++) {
> struct ref_update *update = transaction->updates[i];
>
> if (ref_type(update->refname) == REF_TYPE_NORMAL)
> transaction->updates[normal_nr++] = update;
> else
> add_update_obj(files_transaction, update);
> }
>
> transaction->nr = normal_nr;
> return 0;
> }
Sure, I can make that change.
> Another alternative would be to set
>
> update->flags |= REF_ABNORMAL
>
> for the abnormal references and *leave them* in the original
> transaction
> while also adding them to files_transactions. Then teach non-files
> backends to skip over updates with REF_ABNORMAL.
>
> The reason I thought of this is that long-term I'd like to make it
> possible for some reference updates to fail without aborting the
> transaction. To implement that, we would want a way for
> ref_transaction_commit() to report back to its caller *which* updates
> failed, and an obvious way to do that would be to store the
> reference-specific errors in struct ref_update. If you leave the
> abnormal ref_updates in the main transaction, then my hoped-for
> change
> would be easier.
>
> But that's a separate and hypothetical idea, so you don't have to let
> it
> influence how you implement this patch.
I'm also interested in this idea. Perhaps it would also be nice to
report *why* they fail (e.g. the conflicting ref name). I did a
variant of this with for the journal code, but my way of doing it
turned out to be a bad idea (long story). But I want to stay focused
on the simplest thing possible, for now.
> > int ref_transaction_commit(struct ref_transaction *transaction,
> > struct strbuf *err)
> > {
> > int ret = -1;
> > struct string_list affected_refnames =
> > STRING_LIST_INIT_NODUP;
> > + struct string_list files_affected_refnames =
> > STRING_LIST_INIT_NODUP;
> > + struct ref_transaction *files_transaction = NULL;
> >
> > assert(err);
> >
> > @@ -1237,6 +1275,26 @@ int ref_transaction_commit(struct
> > ref_transaction *transaction,
> > if (ret)
> > goto done;
> >
> > + if (the_refs_backend != &refs_be_files) {
> > + files_transaction = ref_transaction_begin(err);
> > + if (!files_transaction)
> > + goto done;
> > +
> > + ret = move_abnormal_ref_updates(transaction,
> > files_transaction,
> > + err);
> > + if (ret)
> > + goto done;
> > +
> > + /* files backend commit */
> > + if (get_affected_refnames(files_transaction,
> > + &files_affected_r
> > efnames,
> > + err)) {
> > + ret = TRANSACTION_GENERIC_ERROR;
> > + goto done;
> > + }
> > + }
> > +
> > + /* main backend commit */
> > if (get_affected_refnames(transaction, &affected_refnames,
> > err)) {
> > ret = TRANSACTION_GENERIC_ERROR;
> > goto done;
> > @@ -1244,8 +1302,24 @@ int ref_transaction_commit(struct
> > ref_transaction *transaction,
> >
> > ret = the_refs_backend->transaction_commit(transaction,
> >
> > &affected_refnames, err);
> > + if (ret)
> > + goto done;
> > +
> > + if (files_transaction) {
> > + ret =
> > refs_be_files.transaction_commit(files_transaction,
> > +
> > &files_affected_refnames,
> > + err);
> > + if (ret) {
> > + warning(split_transaction_fail_warning);
> > + goto done;
> > + }
> > + }
> > +
> > done:
> > string_list_clear(&affected_refnames, 0);
> > + string_list_clear(&files_affected_refnames, 0);
> > + if (files_transaction)
> > + ref_transaction_free(files_transaction);
> > return ret;
> > }
> >
> > @@ -1285,6 +1359,9 @@ int peel_ref(const char *refname, unsigned
> > char *sha1)
> > int create_symref(const char *ref_target, const char
> > *refs_heads_master,
> > const char *logmsg)
> > {
> > + if (ref_type(ref_target) != REF_TYPE_NORMAL)
> > + return refs_be_files.create_symref(ref_target,
> > refs_heads_master,
> > + logmsg);
> > return the_refs_backend->create_symref(ref_target,
> > refs_heads_master,
> > logmsg);
> > }
> >
>
> Does initial_ref_transaction_commit() need the same treatment?
We only use that for remote refs -- I'm not sure if those can be
symrefs. Wouldn't hurt.
> I think files_rename_ref() will break if one of the references is
> normal
> and one is abnormal. I think it would be OK to prohibit renaming
> abnormal refs entirely (can anybody think of an important use case?),
> but that function should at least do the checks.
The files backend would work fine, but I guess I'll add the check
anyway, since that would be a weird thing to do.
next prev parent reply other threads:[~2016-02-18 2:44 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 19:44 [PATCH v4 00/20] refs backend David Turner
2016-02-05 19:44 ` [PATCH v4 01/21] refs: add a backend method structure with transaction functions David Turner
2016-02-05 19:44 ` [PATCH v4 02/21] refs: add methods for misc ref operations David Turner
2016-02-11 7:45 ` Michael Haggerty
2016-02-12 1:09 ` David Turner
2016-02-05 19:44 ` [PATCH v4 03/21] refs: add methods for the ref iterators David Turner
2016-02-11 8:42 ` Michael Haggerty
2016-02-12 1:08 ` David Turner
2016-02-05 19:44 ` [PATCH v4 04/21] refs: add do_for_each_per_worktree_ref David Turner
2016-02-05 19:44 ` [PATCH v4 05/21] refs: add methods for reflog David Turner
2016-02-05 19:44 ` [PATCH v4 06/21] refs: add method for initial ref transaction commit David Turner
2016-02-05 19:44 ` [PATCH v4 07/21] refs: add method for delete_refs David Turner
2016-02-05 19:44 ` [PATCH v4 08/21] refs: add methods to init refs db David Turner
2016-02-11 8:54 ` Michael Haggerty
2016-02-11 21:15 ` David Turner
2016-02-05 19:44 ` [PATCH v4 09/21] refs: add method to rename refs David Turner
2016-02-11 9:00 ` Michael Haggerty
2016-02-11 21:12 ` David Turner
2016-02-05 19:44 ` [PATCH v4 10/21] refs: make lock generic David Turner
2016-02-05 19:44 ` [PATCH v4 11/21] refs: move duplicate check to common code David Turner
2016-02-05 19:44 ` [PATCH v4 12/21] refs: allow log-only updates David Turner
2016-02-11 10:03 ` Michael Haggerty
2016-02-11 21:23 ` David Turner
2016-02-05 19:44 ` [PATCH v4 13/21] refs: resolve symbolic refs first David Turner
2016-02-12 14:09 ` Michael Haggerty
2016-02-18 0:29 ` David Turner
2016-02-18 11:59 ` Michael Haggerty
2016-02-05 19:44 ` [PATCH v4 14/21] refs: always handle non-normal refs in files backend David Turner
2016-02-12 15:07 ` Michael Haggerty
2016-02-18 2:44 ` David Turner [this message]
2016-02-18 12:07 ` Michael Haggerty
2016-02-18 18:32 ` David Turner
2016-02-05 19:44 ` [PATCH v4 15/21] init: allow alternate ref strorage to be set for new repos David Turner
2016-02-12 15:26 ` Michael Haggerty
2016-02-17 20:47 ` David Turner
2016-02-18 14:12 ` Michael Haggerty
2016-02-05 19:44 ` [PATCH v4 16/21] refs: check submodules ref storage config David Turner
2016-02-05 19:44 ` [PATCH v4 17/21] clone: allow ref storage backend to be set for clone David Turner
2016-02-05 19:44 ` [PATCH v4 18/21] svn: learn ref-storage argument David Turner
2016-02-05 19:44 ` [PATCH v4 19/21] refs: add register_ref_storage_backends() David Turner
2016-02-12 15:42 ` Michael Haggerty
2016-02-17 20:32 ` David Turner
2016-02-05 19:44 ` [PATCH v4 20/21] refs: add LMDB refs storage backend David Turner
2016-02-11 8:48 ` Michael Haggerty
2016-02-11 21:21 ` David Turner
2016-02-12 17:01 ` Michael Haggerty
2016-02-13 1:23 ` David Turner
2016-02-14 12:04 ` Duy Nguyen
2016-02-15 9:57 ` Duy Nguyen
2016-02-16 22:01 ` David Turner
2016-02-17 20:32 ` David Turner
2016-02-05 19:44 ` [PATCH v4 21/21] refs: tests for lmdb backend David Turner
2016-02-08 23:37 ` [PATCH v4 00/20] refs backend Junio C Hamano
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=1455763440.7528.71.camel@twopensource.com \
--to=dturner@twopensource.com \
--cc=git@vger.kernel.org \
--cc=mhagger@alum.mit.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).