From: Junio C Hamano <gitster@pobox•com>
To: Eric Sunshine <sunshine@sunshineco•com>
Cc: David Turner <dturner@twopensource•com>,
Git List <git@vger•kernel.org>,
Michael Haggerty <mhagger@alum•mit.edu>
Subject: Re: [PATCH v6 6/7] git-reflog: add create and exists functions
Date: Tue, 30 Jun 2015 09:07:32 -0700 [thread overview]
Message-ID: <xmqqbnfx89iz.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAPig+cROJJNTcZnZfMP0meA8ZWGcSHcQCMTCkuC+kn_+OQZ-zA@mail.gmail.com> (Eric Sunshine's message of "Tue, 30 Jun 2015 03:34:10 -0400")
Eric Sunshine <sunshine@sunshineco•com> writes:
>> + for (i = start; i < argc; i++) {
>> + if (safe_create_reflog(argv[i], &err, 1)) {
>> + error("could not create reflog %s: %s", argv[i],
>> + err.buf);
>> + status = 1;
>> + strbuf_release(&err);
>
> This feels a bit dirty.
Hmm, I do not share that feeling. I wouldn't be surprised if you
found a lot of existing codepaths that run _init() a strbuf once,
work on it and then _release() once a section of code is done with
it, reuse it for further (unrelated) processing, knowing that
_release() implicitly did _init() and the strbuf is ready to use
after that. I thought that was a very well established pattern.
> While it's true that the current
> implementation of strbuf_release() re-initializes the strbuf (so
> you're not technically wrong by re-using it), that's an implementation
> detail; and indeed, the strbuf_release() documentation says:
>
> Release a string buffer and the memory it used. You should not
> use the string buffer after using this function, unless you
> initialize it again.
Hmph. Perhaps the doc is wrong? ;-)
> Alternatives would be strbuf_reset() or declaring and releasing the
> strbuf within the for-loop scope.
Because _reset() just rewinds the .len pointer without deallocating,
you would need an extra _release() before it goes out of scope. If
it is expected that the strbuf will be reused for a number of times,
the length of the string each iteration uses is similar, and you
will iterate the loop many times, "_reset() each time and _release()
to clean-up" pattern would save many calls to realloc/free.
next prev parent reply other threads:[~2015-06-30 16:07 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-29 20:17 [PATCH v6 0/7] refs backend preamble David Turner
2015-06-29 20:17 ` [PATCH v6 1/7] refs.c: add err arguments to reflog functions David Turner
2015-07-06 15:53 ` Michael Haggerty
2015-07-07 22:41 ` David Turner
2015-07-08 10:59 ` Michael Haggerty
2015-07-08 17:11 ` Junio C Hamano
2015-07-09 6:47 ` Michael Haggerty
2015-06-29 20:17 ` [PATCH v6 2/7] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs David Turner
2015-07-06 16:00 ` Michael Haggerty
2015-06-29 20:17 ` [PATCH v6 3/7] bisect: treat BISECT_HEAD as a ref David Turner
2015-06-29 20:17 ` [PATCH v6 4/7] refs: Break out check for reflog autocreation David Turner
2015-06-29 20:17 ` [PATCH v6 5/7] refs: new public ref function: safe_create_reflog David Turner
2015-07-06 16:21 ` Michael Haggerty
2015-07-07 23:18 ` David Turner
2015-07-08 11:04 ` Michael Haggerty
2015-06-29 20:17 ` [PATCH v6 6/7] git-reflog: add create and exists functions David Turner
2015-06-30 7:34 ` Eric Sunshine
2015-06-30 15:57 ` David Turner
2015-06-30 16:07 ` Junio C Hamano [this message]
2015-06-30 18:20 ` Eric Sunshine
2015-06-30 19:48 ` Junio C Hamano
2015-06-30 21:19 ` David Turner
2015-06-30 21:28 ` Junio C Hamano
2015-07-06 16:51 ` Michael Haggerty
2015-07-08 0:49 ` David Turner
2015-07-08 13:16 ` Michael Haggerty
2015-07-08 20:12 ` David Turner
2015-06-29 20:17 ` [PATCH v6 7/7] git-stash: use git-reflog instead of creating files David Turner
2015-06-29 21:03 ` Junio C Hamano
2015-06-29 20:31 ` [PATCH v6 0/7] refs backend preamble Junio C Hamano
2015-06-29 20:48 ` David Turner
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=xmqqbnfx89iz.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=dturner@twopensource$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=mhagger@alum$(echo .)mit.edu \
--cc=sunshine@sunshineco$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox