From: Junio C Hamano <gitster@pobox.com>
To: Johan Herland <johan@herland.net>
Cc: Git mailing list <git@vger.kernel.org>,
"Kyle J. McKay" <mackyle@gmail.com>,
"James H. Fisher" <jhf@trifork.com>,
Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCHv4 5/9] builtin/notes: Simplify early exit code in add()
Date: Tue, 11 Nov 2014 07:53:02 -0800 [thread overview]
Message-ID: <xmqqvbml7mzl.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CALKQrgdBhm91tipHRQ3sF_DacSh5nRJmS7eP4S5Z4vB8R8O4_w@mail.gmail.com> (Johan Herland's message of "Tue, 11 Nov 2014 01:49:58 +0100")
Johan Herland <johan@herland.net> writes:
> On Mon, Nov 10, 2014 at 9:36 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Johan Herland <johan@herland.net> writes:
>>
>>> Signed-off-by: Johan Herland <johan@herland.net>
>>> ---
>>> builtin/notes.c | 12 +++++-------
>>> 1 file changed, 5 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/builtin/notes.c b/builtin/notes.c
>>> index 1017472..f1480cf 100644
>>> --- a/builtin/notes.c
>>> +++ b/builtin/notes.c
>>> @@ -399,7 +399,7 @@ static int append_edit(int argc, const char **argv, const char *prefix);
>>>
>>> static int add(int argc, const char **argv, const char *prefix)
>>> {
>>> - int retval = 0, force = 0;
>>> + int force = 0;
>>> const char *object_ref;
>>> struct notes_tree *t;
>>> unsigned char object[20], new_note[20];
>>> @@ -441,6 +441,8 @@ static int add(int argc, const char **argv, const char *prefix)
>>>
>>> if (note) {
>>> if (!force) {
>>> + free_note_data(&d);
>>> + free_notes(t);
>>> if (!d.given) {
>>
>> It looks a bit strange to refer to d.given after calling a function
>> that sounds as if it is meant to clear what is recorded in and to
>> invalidate &d; yes, I can read the implementation to see that
>> d.given keeps its stale value, but that is something other people
>> may want to "clean up" later and this reference to d.given will get
>> in the way when that happens.
>
> Yes, that was obviously an oversight on my part.
>
>> At this point of the code, it makes sense to free t in preparation
>> to either switching to append codepath or erroring out, but does &d
>> have anything in it already to necessitate its freeing?
>
> Actually, no, although verifying that required double-checking that
> each of the -m/-F/-c/-C parsers which store data into &d, do in fact
> set d.given.
>
> I suggest to either move the free_note_data(&d) call below the "if
> (!d.given)" block, or reorganize into this (which at the moment reads
> better to me):
>
> if (note) {
> if (!force) {
> free_notes(t);
> if (d.given) {
> free_note_data(&d);
> return error(_("Cannot add notes. "
> "Found existing notes for object %s. "
> "Use '-f' to overwrite existing notes"),
> sha1_to_hex(object));
> }
> /*
> * Redirect to "edit" subcommand.
> *
> * We only end up here if none of -m/-F/-c/-C or -f are
> * given. The original args are therefore still in
> * argv[0-1].
> */
> argv[0] = "edit";
> return append_edit(argc, argv, prefix);
> }
> fprintf(stderr, _("Overwriting existing notes for object %s\n"),
> sha1_to_hex(object));
> }
>
> This keeps the two free_* calls close together, only separated by if
> (d.given), which nicely indicates whether we need to call
> free_notes_data(&d) at all.
>
> If that looks good to you, do you want a re-roll, or is it easier to
> fix up yourself?
I strongly prefer reroll for anything bigger than single-line tweaks
to avoid mistakes.
Thans.
next prev parent reply other threads:[~2014-11-11 15:53 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-09 12:30 [PATCHv4 0/9] Handling empty notes Johan Herland
2014-11-09 12:30 ` [PATCHv4 1/9] builtin/notes: Fix premature failure when trying to add the empty blob Johan Herland
2014-11-09 12:30 ` [PATCHv4 2/9] t3301: Verify that 'git notes' removes empty notes by default Johan Herland
2014-11-09 12:30 ` [PATCHv4 3/9] builtin/notes: Improve naming Johan Herland
2014-11-09 12:30 ` [PATCHv4 4/9] builtin/notes: Refactor note file path into struct note_data Johan Herland
2014-11-09 12:30 ` [PATCHv4 5/9] builtin/notes: Simplify early exit code in add() Johan Herland
2014-11-10 20:36 ` Junio C Hamano
2014-11-11 0:49 ` Johan Herland
2014-11-11 15:53 ` Junio C Hamano [this message]
2014-11-09 12:30 ` [PATCHv4 6/9] builtin/notes: Split create_note() to clarify add vs. remove logic Johan Herland
2014-11-09 12:30 ` [PATCHv4 7/9] builtin/notes: Add --allow-empty, to allow storing empty notes Johan Herland
2014-11-09 12:30 ` [PATCHv4 8/9] notes: Empty notes should be shown by 'git log' Johan Herland
2014-11-09 12:30 ` [PATCHv4 9/9] t3301: Modernize Johan Herland
2014-11-10 20:42 ` Junio C Hamano
2014-11-11 1:04 ` Johan Herland
2014-11-11 1:07 ` Eric Sunshine
2014-11-11 1:50 ` Johan Herland
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=xmqqvbml7mzl.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jhf@trifork.com \
--cc=johan@herland.net \
--cc=mackyle@gmail.com \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.