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$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jhf@trifork$(echo .)com \
--cc=johan@herland$(echo .)net \
--cc=mackyle@gmail$(echo .)com \
--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