Re: [PATCH v4 12/27] replace.c: use the ref transaction functions for updates
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Apr 29, 2014, 00:44 UTC
- Message-ID
- <CAPig+cSWMK_kyVvaD8QCfZmPu4JVT+nOJZJLteHhDao0umHLbA@mail.gmail.com>
- In-Reply-To
- <1398725682-30782-13-git-send-email-sahlberg@google.com>
On Mon, Apr 28, 2014 at 6:54 PM, Ronnie Sahlberg <sahlberg@google.com> wrote:
Show 36 quoted lines
> Update replace.c to use ref transactions for updates.
>
> Signed-off-by: Ronnie Sahlberg <sahlberg@google.com>
> ---
> builtin/replace.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/builtin/replace.c b/builtin/replace.c
> index b62420a..b037b29 100644
> --- a/builtin/replace.c
> +++ b/builtin/replace.c
> @@ -129,7 +129,8 @@ static int replace_object(const char *object_ref, const char *replace_ref,
> unsigned char object[20], prev[20], repl[20];
> enum object_type obj_type, repl_type;
> char ref[PATH_MAX];
> - struct ref_lock *lock;
> + struct ref_transaction *transaction;
> + struct strbuf err = STRBUF_INIT;
>
> if (get_sha1(object_ref, object))
> die("Failed to resolve '%s' as a valid ref.", object_ref);
> @@ -157,11 +158,12 @@ static int replace_object(const char *object_ref, const char *replace_ref,
> else if (!force)
> die("replace ref '%s' already exists", ref);
>
> - lock = lock_any_ref_for_update(ref, prev, 0, NULL);
> - if (!lock)
> - die("%s: cannot lock the ref", ref);
> - if (write_ref_sha1(lock, repl, NULL) < 0)
> - die("%s: cannot update the ref", ref);
> + transaction = ref_transaction_begin();
> + if (!transaction ||
> + ref_transaction_update(transaction, ref, repl, prev,
> + 0, !is_null_sha1(prev)) ||
> + ref_transaction_commit(transaction, NULL, &err))
> + die(_("%s: failed to replace ref: %s"), ref, err.buf);Even though 'err' will be empty after this conditional, would strbuf_release(&err) here be warranted to future-proof it? Today's implementation of strbuf will not have allocated any memory, but perhaps a future change might pre-allocate (unlikely though that is), which would leak here.
> return 0; > } > -- > 1.9.1.528.g98b8868.dirty