git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Tanay Abhra <tanayabh@gmail.com>
Cc: Git List <git@vger.kernel.org>,
	Ramkumar Ramachandra <artagnon@gmail.com>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: [RFC/PATCH] notes-util.c: replace git_config with git_config_get_string
Date: Sun, 29 Jun 2014 07:01:31 -0400	[thread overview]
Message-ID: <CAPig+cSRBk5Q2amvFXyjH4dpoP83qbYUEUizE7v38Wh8Ofnfpw@mail.gmail.com> (raw)
In-Reply-To: <53ABD78E.3050800@gmail.com>

On Thu, Jun 26, 2014 at 4:19 AM, Tanay Abhra <tanayabh@gmail.com> wrote:
> On 6/25/2014 1:24 PM, Eric Sunshine wrote:
>> On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra <tanayabh@gmail.com> wrote:
>>> Use git_config_get_string instead of git_config to take advantage of
>>> the config hash-table api which provides a cleaner control flow.
>>>
>>> Signed-off-by: Tanay Abhra <tanayabh@gmail.com>
>>> ---
>>>  notes-utils.c | 31 +++++++++++++++----------------
>>>  1 file changed, 15 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/notes-utils.c b/notes-utils.c
>>> index a0b1d7b..fdc9912 100644
>>> --- a/notes-utils.c
>>> +++ b/notes-utils.c
>>> @@ -68,22 +68,23 @@ static combine_notes_fn parse_combine_notes_fn(const char *v)
>>>                 return NULL;
>>>  }
>>>
>>> -static int notes_rewrite_config(const char *k, const char *v, void *cb)
>>> +static void notes_rewrite_config(struct notes_rewrite_cfg *c)
>>>  {
>>> -       struct notes_rewrite_cfg *c = cb;
>>> -       if (starts_with(k, "notes.rewrite.") && !strcmp(k+14, c->cmd)) {
>>> -               c->enabled = git_config_bool(k, v);
>>> -               return 0;
>>> -       } else if (!c->mode_from_env && !strcmp(k, "notes.rewritemode")) {
>>> +       struct strbuf key = STRBUF_INIT;
>>> +       const char *v;
>>> +       strbuf_addf(&key, "notes.rewrite.%s", c->cmd);
>>> +
>>> +       if (!git_config_get_string(key.buf, &v))
>>> +               c->enabled = git_config_bool(key.buf, v);
>>> +
>>> +       if (!c->mode_from_env && !git_config_get_string("notes.rewritemode", &v)) {
>>>                 if (!v)
>>> -                       return config_error_nonbool(k);
>>> +                       config_error_nonbool("notes.rewritemode");
>>
>> There's a behavior change here. In the original code, the callback
>> function would return -1, which would cause the program to die() if
>> the config.c:die_on_error flag was set. The new code merely emits an
>> error.
>
> Is this change serious enough? Can I ignore it?

I don't know. Even within this single function there is no consistency
about whether such problems should die() or just emit a message and
continue. For instance:

- if "notes.rewritemode" is bool, it die()s.

- if "notes.rewritemode" doesn't specify a recognized mode, it
error()s but continues

- if "notes.rewriteref" doesn't start with "refs/notes/, it warning()s
and continues

It would be nice to hear an opinion from someone more invested in the
config system.

>>>                 c->combine = parse_combine_notes_fn(v);
>>
>> Worse: Though you correctly emit an error when 'v' is NULL, you then
>> (incorrectly) invoke parse_combine_notes_fn() with that NULL value,
>> which will result in a crash.
>>
>
> Noted.
>
>>> -               if (!c->combine) {
>>> +               if (!c->combine)
>>>                         error(_("Bad notes.rewriteMode value: '%s'"), v);
>>> -                       return 1;
>>> -               }
>>> -               return 0;
>>> -       } else if (!c->refs_from_env && !strcmp(k, "notes.rewriteref")) {
>>> +       }
>>> +       if (!c->refs_from_env && !git_config_get_string("notes.rewriteref", &v)) {
>>>                 /* note that a refs/ prefix is implied in the
>>>                  * underlying for_each_glob_ref */
>>>                 if (starts_with(v, "refs/notes/"))
>>> @@ -91,10 +92,8 @@ static int notes_rewrite_config(const char *k, const char *v, void *cb)
>>>                 else
>>>                         warning(_("Refusing to rewrite notes in %s"
>>>                                 " (outside of refs/notes/)"), v);
>>> -               return 0;
>>>         }
>>> -
>>> -       return 0;
>>> +       strbuf_release(&key);
>>
>> It would be better to release the strbuf immediately after its final
>> use rather than waiting until the end of function. Not only does that
>> reduce cognitive load on people reading the code, but it also reduces
>> likelihood of 'key' being leaked if some future programmer inserts an
>> early 'return' into the function for some reason.
>>
>
> Noted. Thanks.
>
>>>  }
>>>
>>>
>>> @@ -123,7 +122,7 @@ struct notes_rewrite_cfg *init_copy_notes_for_rewrite(const char *cmd)
>>>                 c->refs_from_env = 1;
>>>                 string_list_add_refs_from_colon_sep(c->refs, rewrite_refs_env);
>>>         }
>>> -       git_config(notes_rewrite_config, c);
>>> +       notes_rewrite_config(c);
>>>         if (!c->enabled || !c->refs->nr) {
>>>                 string_list_clear(c->refs, 0);
>>>                 free(c->refs);
>>> --
>>> 1.9.0.GIT
>>

  reply	other threads:[~2014-06-29 11:01 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-23 10:41 [RFC/PATCH V2] alias.c: replace git_config with git_config_get_string Tanay Abhra
2014-06-23 10:41 ` [RFC/PATCH V2] branch.c: " Tanay Abhra
2014-06-25  4:45   ` Eric Sunshine
2014-06-26  8:09     ` Tanay Abhra
2014-06-29 11:06       ` Eric Sunshine
2014-06-23 10:41 ` [RFC/PATCH] imap-send.c: " Tanay Abhra
2014-06-25  7:09   ` Eric Sunshine
2014-06-26  8:14     ` Tanay Abhra
2014-06-26 16:50   ` Matthieu Moy
2014-06-26 23:57     ` Karsten Blees
2014-06-23 10:41 ` [RFC/PATCH] notes-util.c: " Tanay Abhra
2014-06-25  7:54   ` Eric Sunshine
2014-06-26  8:19     ` Tanay Abhra
2014-06-29 11:01       ` Eric Sunshine [this message]
2014-06-30 13:34         ` Karsten Blees
2014-06-30 14:32           ` Eric Sunshine
2014-06-30 14:54             ` Karsten Blees
2014-06-30 14:39           ` Tanay Abhra
2014-06-30 15:56             ` Karsten Blees
2014-06-30 16:21               ` Tanay Abhra
2014-06-30 17:52               ` Junio C Hamano
2014-07-01  8:36             ` Matthieu Moy
2014-06-23 10:41 ` [RFC/PATCH] notes.c: " Tanay Abhra
2014-06-25  8:06   ` Eric Sunshine
2014-06-26  8:20     ` Tanay Abhra
2014-06-23 10:41 ` [RFC/PATCH] pager.c: " Tanay Abhra
2014-06-25  3:59   ` Eric Sunshine
2014-06-26  8:24     ` Tanay Abhra
2014-06-26 18:46     ` Karsten Blees
2014-06-27 11:55       ` Matthieu Moy
2014-06-27 16:57         ` Karsten Blees
2014-06-27 19:19           ` Matthieu Moy
2014-06-28  5:20             ` Karsten Blees
2014-06-28  6:01               ` Matthieu Moy
2014-06-28 14:29                 ` Karsten Blees
2014-06-29 12:04                   ` Matthieu Moy
2014-06-23 22:38 ` [RFC/PATCH V2] alias.c: " Jonathan Nieder
2014-06-24  1:50   ` Tanay Abhra
2014-06-25  2:12 ` Eric Sunshine
2014-06-26  8:24   ` Tanay Abhra
2014-06-26 16:39 ` Matthieu Moy

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=CAPig+cSRBk5Q2amvFXyjH4dpoP83qbYUEUizE7v38Wh8Ofnfpw@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=tanayabh@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).