Ronnie Sahlberg wrote:

> Change the update_ref helper function to use a ref transaction internally.
> 
> Signed-off-by: Ronnie Sahlberg <sahlb...@google.com>
> ---
>  refs.c | 25 +++++++++++++++++++++----
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/refs.c b/refs.c
> index 6e5e940..0476892 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -3416,11 +3416,28 @@ int update_ref(const char *action, const char 
> *refname,
>              const unsigned char *sha1, const unsigned char *oldval,
>              int flags, enum action_on_err onerr)
>  {
> -     struct ref_lock *lock;
> -     lock = update_ref_lock(refname, oldval, flags, NULL, onerr);
> -     if (!lock)
> +     struct ref_transaction *t;
> +     struct strbuf err = STRBUF_INIT;
> +
> +     t = ref_transaction_begin();
> +     if ((!t ||
> +         ref_transaction_update(t, refname, sha1, oldval, flags,
> +                                !!oldval)) ||
> +         (ref_transaction_commit(t, action, &err) && !(t = NULL))) {
> +             const char *str = "update_ref failed for ref '%s': %s";
> +
> +             ref_transaction_rollback(t);
> +             switch (onerr) {
> +             case UPDATE_REFS_MSG_ON_ERR:
> +                     error(str, refname, err.buf); break;
> +             case UPDATE_REFS_DIE_ON_ERR:
> +                     die(str, refname, err.buf); break;
> +             case UPDATE_REFS_QUIET_ON_ERR: break;
> +             }

The error string already contains the refname, so it would make sense to
do

                case UPDATE_REFS_MSG_ON_ERR:
                        error("%s", err.buf); break;

etc here.

It occurs to me now that if ref_transaction_begin fails, presumably
the error string would not contain the refname.  I want to say that
the refname wouldn't help much in diagnosing or recovering from the
problem in that case so it would still be okay to just do error("%s",
err.buf).  What do you think?

Thanks,
Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to