Re: [PATCH v4 12/27] replace.c: use the ref transaction functions for updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 28, 2014 at 5:44 PM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
> On Mon, Apr 28, 2014 at 6:54 PM, Ronnie Sahlberg <sahlberg@xxxxxxxxxx> wrote:
>> Update replace.c to use ref transactions for updates.
>>
>> Signed-off-by: Ronnie Sahlberg <sahlberg@xxxxxxxxxx>
>> ---
>>  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.


Thanks.


I have no strong feelings either way.
A previous patch got a comment to remove a strbuf_release() because we
knew in that
code path that the string would be empty and thus the call was superfluous.

So one for and one against so far.
I will leave as is until there is more consensus.



>
>>         return 0;
>>  }
>> --
>> 1.9.1.528.g98b8868.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]