All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Ronnie Sahlberg <sahlberg@google.com>
Cc: git@vger.kernel.org, mhagger@alum.mit.edu
Subject: Re: [PATCH v6 08/42] refs.c: change ref_transaction_update() to do error checking and return status
Date: Wed, 14 May 2014 16:40:15 -0700	[thread overview]
Message-ID: <20140514234015.GE9218@google.com> (raw)
In-Reply-To: <1398976662-6962-9-git-send-email-sahlberg@google.com>

Ronnie Sahlberg wrote:

> Update ref_transaction_update() do some basic error checking and return
> true on error. Update all callers to check ref_transaction_update() for error.
> There are currently no conditions in _update that will return error but there
> will be in the future.
>
> Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
> ---
>  builtin/update-ref.c | 10 ++++++----
>  refs.c               |  9 +++++++--
>  refs.h               | 10 +++++-----
>  3 files changed, 18 insertions(+), 11 deletions(-)

Revisiting comments from [1]:

 * When I call ref_transaction_update, what does it mean that I get
   a nonzero return value?  Does it mean the _update failed and had
   no effect?  What will I want to do next: should I try again or
   print an error and exit?

   Ideally I should be able to answer these questions by reading
   the signature of ref_transaction_update and the comment documenting
   it.  The comment doesn't say anything about what errors
   mean here.

 * the error message change for the have_old && !old_sha1 case (to add
   "BUG:" so users know the impossible has happened and translators
   know not to bother with it) seems to have snuck ahead into patch 28
   (refs.c: add transaction.status and track OPEN/CLOSED/ERROR).

 * It would be easier to make sense of the error path (does the error
   message have enough information?  Will the user be bewildered?)
   if there were an example of how ref_transaction_update can fail.

   There still doesn't seem to be one by the end of the series.

The general idea still seems sensible.

Thanks,
Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/246437/focus=247115

  parent reply	other threads:[~2014-05-14 23:40 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-01 20:37 [PATCH v6 00/42] Use ref transactions for all ref updates Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 01/42] refs.c: constify the sha arguments for ref_transaction_create|delete|update Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 02/42] refs.c: allow passing NULL to ref_transaction_free Ronnie Sahlberg
2014-05-13 22:44   ` Jonathan Nieder
2014-05-13 22:52     ` Ronnie Sahlberg
2014-05-14 15:14     ` Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 03/42] refs.c: add a strbuf argument to ref_transaction_commit for error logging Ronnie Sahlberg
2014-05-13 23:10   ` Jonathan Nieder
2014-05-14 15:20     ` Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 04/42] refs.c: make ref_update_reject_duplicates take a strbuf argument for errors Ronnie Sahlberg
2014-05-14  0:04   ` Jonathan Nieder
2014-05-14 15:24     ` Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 05/42] update-ref.c: log transaction error from the update_ref Ronnie Sahlberg
2014-05-14 22:08   ` Jonathan Nieder
2014-05-15 15:47     ` Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 06/42] refs.c: make update_ref_write update a strbuf on failure Ronnie Sahlberg
2014-05-14 23:04   ` Jonathan Nieder
2014-05-01 20:37 ` [PATCH v6 07/42] refs.c: remove the onerr argument to ref_transaction_commit Ronnie Sahlberg
2014-05-14 23:06   ` Jonathan Nieder
2014-05-01 20:37 ` [PATCH v6 08/42] refs.c: change ref_transaction_update() to do error checking and return status Ronnie Sahlberg
2014-05-05 13:08   ` Michael Haggerty
2014-05-05 23:09     ` Ronnie Sahlberg
2014-05-14 23:40   ` Jonathan Nieder [this message]
2014-05-15 16:06     ` Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 09/42] refs.c: change ref_transaction_create " Ronnie Sahlberg
2014-05-15  0:04   ` Jonathan Nieder
2014-05-15 16:23     ` Ronnie Sahlberg
2014-05-15 16:56       ` Jonathan Nieder
2014-05-01 20:37 ` [PATCH v6 10/42] refs.c: ref_transaction_delete to check for error " Ronnie Sahlberg
2014-05-15  0:19   ` Jonathan Nieder
2014-05-15 16:26     ` Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 11/42] tag.c: use ref transactions when doing updates Ronnie Sahlberg
2014-05-15  0:27   ` Jonathan Nieder
2014-05-15 16:45     ` Ronnie Sahlberg
2014-05-15 16:53       ` Jonathan Nieder
2014-05-01 20:37 ` [PATCH v6 12/42] replace.c: use the ref transaction functions for updates Ronnie Sahlberg
2014-05-15  0:30   ` Jonathan Nieder
2014-05-15 16:50     ` Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 13/42] commit.c: use ref transactions " Ronnie Sahlberg
2014-05-15  1:11   ` Jonathan Nieder
2014-05-15 16:53     ` Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 14/42] sequencer.c: use ref transactions for all ref updates Ronnie Sahlberg
2014-05-15 17:35   ` Jonathan Nieder
2014-05-01 20:37 ` [PATCH v6 15/42] fast-import.c: change update_branch to use ref transactions Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 16/42] branch.c: use ref transaction for all ref updates Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 17/42] refs.c: change update_ref to use a transaction Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 18/42] refs.c: free the transaction before returning when number of updates is 0 Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 19/42] refs.c: ref_transaction_commit should not free the transaction Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 20/42] fetch.c: clear errno before calling functions that might set it Ronnie Sahlberg
2014-05-02  4:11   ` Eric Sunshine
2014-05-02 14:48     ` Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 21/42] fetch.c: change s_update_ref to use a ref transaction Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 22/42] fetch.c: use a single ref transaction for all ref updates Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 23/42] receive-pack.c: use a reference transaction for updating the refs Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 24/42] fast-import.c: use a ref transaction when dumping tags Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 25/42] walker.c: use ref transaction for ref updates Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 26/42] refs.c: make write_ref_sha1 static Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 27/42] refs.c: make lock_ref_sha1 static Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 28/42] refs.c: add transaction.status and track OPEN/CLOSED/ERROR Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 29/42] refs.c: remove the update_ref_lock function Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 30/42] refs.c: remove the update_ref_write function Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 31/42] refs.c: remove lock_ref_sha1 Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 32/42] refs.c: make prune_ref use a transaction to delete the ref Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 33/42] refs.c: make delete_ref use a transaction Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 34/42] refs.c: pass the ref log message to _create/delete/update instead of _commit Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 35/42] refs.c: pass NULL as *flags to read_ref_full Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 36/42] refs.c: pack all refs before we start to rename a ref Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 37/42] refs.c: move the check for valid refname to lock_ref_sha1_basic Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 38/42] refs.c: call lock_ref_sha1_basic directly from commit Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 39/42] refs.c: add a new flag for transaction delete for refs we know are packed only Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 40/42] refs.c: pass a skip list to name_conflict_fn Ronnie Sahlberg
2014-05-02  4:22   ` Eric Sunshine
2014-05-02 14:49     ` Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 41/42] refs.c: make rename_ref use a transaction Ronnie Sahlberg
2014-05-01 20:37 ` [PATCH v6 42/42] refs.c: remove forward declaraion of write_ref_sha1 Ronnie Sahlberg
2014-05-05 12:57 ` [PATCH v6 00/42] Use ref transactions for all ref updates Michael Haggerty
2014-05-05 15:09   ` Ronnie Sahlberg
2014-05-13 20:25 ` Jonathan Nieder

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=20140514234015.GE9218@google.com \
    --to=jrnieder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=mhagger@alum.mit.edu \
    --cc=sahlberg@google.com \
    /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.