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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.