git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Apr 29, 2014, 18:29 UTC
Message-ID
<CAPig+cQ5br8icrUPwP7=zuQnXD4-tNU5rjZ8AWhCWGwT5KegfA@mail.gmail.com>
In-Reply-To
<CAL=YDWn9TJsygZdgY2gXVBScFjO3zbrbJ5XORc2ZLaY-M8PmSw@mail.gmail.com>
On Tue, Apr 29, 2014 at 12:18 PM, Ronnie Sahlberg <sahlberg@google.com> wrote:
Show 49 quoted lines
> On Mon, Apr 28, 2014 at 5:44 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>> On Mon, Apr 28, 2014 at 6:54 PM, Ronnie Sahlberg <sahlberg@google.com> wrote:
>>> 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.
>
> 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.

Indeed, I realized later that the reason I gave for possibly adding the strbuf_release() was effectively bogus. Code throughout the project ignores strbuff_release() when it is obvious that the strbuf hasn't been used. Such code looks like this:

func() {
    struct strbuf foo = STRBUF_INIT;
    ...code not touching 'foo'...
    if (...)
        return;
    ...code touching 'foo'...
    strbuf_release(&foo);
}

At the point of early return, it's obvious at a glance that no content has been added to 'foo'.

It was only a little while ago that I came to understand why the code in this patch bothered me:

func() {
    struct strbuf foo = STRBUF_INIT;
    if (bar(&foo))
        die(...);
    ...return or fall off end without releasing 'foo'...
}

The problem is that it's not so easy to see that it's safe to "leak" the strbuf without detouring through the documentation of bar() and possibly its implementation as well, before finally resuming the reading of func(). That extra cost of having to study bar() will likely be paid by most readers of func() who are concerned about the missing strbuf_release(). The cognitive burden is greater.

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

Fair enough. The fact that the variable is named 'err' in this case might be enough to allow one to infer, without detouring through bar(), that the missing strbuf_release() is intentional.

Previous: Ronnie SahlbergNext: Ronnie Sahlberg
Message 18 of 38 in “Use ref transactions for all ref updates”
  1. 00/27 Use ref transactions for all ref updatesRonnie Sahlberg, Apr 28, 2014
  2. 01/27 refs.c: constify the sha arguments for ref_transaction_create|delete|updateRonnie Sahlberg, Apr 28, 2014
  3. 02/27 refs.c: allow passing NULL to ref_transaction_freeRonnie Sahlberg, Apr 28, 2014
  4. 03/27 refs.c: add a strbuf argument to ref_transaction_commit for error loggingRonnie Sahlberg, Apr 28, 2014
  5. 04/27 refs.c: make ref_update_reject_duplicates take a strbuf argument for errorsRonnie Sahlberg, Apr 28, 2014
  6. 05/27 update-ref.c: log transaction error from the update_refRonnie Sahlberg, Apr 28, 2014
  7. 06/27 refs.c: make update_ref_write update a strbuf on failureRonnie Sahlberg, Apr 28, 2014
  8. 07/27 refs.c: remove the onerr argument to ref_transaction_commitRonnie Sahlberg, Apr 28, 2014
  9. 08/27 refs.c: change ref_transaction_update() to do error checking and return statusRonnie Sahlberg, Apr 28, 2014
  10. Eric SunshineApr 29, 2014
  11. Ronnie SahlbergApr 29, 2014
  12. 09/27 refs.c: change ref_transaction_create to do error checking and return statusRonnie Sahlberg, Apr 28, 2014
  13. 10/27 refs.c: ref_transaction_delete to check for error and return statusRonnie Sahlberg, Apr 28, 2014
  14. 11/27 tag.c: use ref transactions when doing updatesRonnie Sahlberg, Apr 28, 2014
  15. 12/27 replace.c: use the ref transaction functions for updatesRonnie Sahlberg, Apr 28, 2014
  16. Eric SunshineApr 29, 2014
  17. Ronnie SahlbergApr 29, 2014
  18. Eric SunshineApr 29, 2014
  19. 13/27 commit.c: use ref transactions for updatesRonnie Sahlberg, Apr 28, 2014
  20. 14/27 sequencer.c: use ref transactions for all ref updatesRonnie Sahlberg, Apr 28, 2014
  21. 15/27 fast-import.c: change update_branch to use ref transactionsRonnie Sahlberg, Apr 28, 2014
  22. Eric SunshineApr 29, 2014
  23. Ronnie SahlbergApr 29, 2014
  24. Junio C HamanoApr 29, 2014
  25. 16/27 branch.c: use ref transaction for all ref updatesRonnie Sahlberg, Apr 28, 2014
  26. 17/27 refs.c: change update_ref to use a transactionRonnie Sahlberg, Apr 28, 2014
  27. 18/27 refs.c: free the transaction before returning when number of updates is 0Ronnie Sahlberg, Apr 28, 2014
  28. 19/27 refs.c: ref_transaction_commit should not free the transactionRonnie Sahlberg, Apr 28, 2014
  29. 20/27 fetch.c: clear errno before calling functions that might set itRonnie Sahlberg, Apr 28, 2014
  30. 21/27 fetch.c: change s_update_ref to use a ref transactionRonnie Sahlberg, Apr 28, 2014
  31. 22/27 fetch.c: use a single ref transaction for all ref updatesRonnie Sahlberg, Apr 28, 2014
  32. 23/27 receive-pack.c: use a reference transaction for updating the refsRonnie Sahlberg, Apr 28, 2014
  33. 24/27 fast-import.c: use a ref transaction when dumping tagsRonnie Sahlberg, Apr 28, 2014
  34. 25/27 walker.c: use ref transaction for ref updatesRonnie Sahlberg, Apr 28, 2014
  35. 26/27 refs.c: make write_ref_sha1 staticRonnie Sahlberg, Apr 28, 2014
  36. 27/27 refs.c: make lock_ref_sha1 staticRonnie Sahlberg, Apr 28, 2014
  37. Junio C HamanoApr 29, 2014
  38. Ronnie SahlbergApr 29, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.