From: Tanay Abhra <tanayabh@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: git@vger.kernel.org, Ramkumar Ramachandra <artagnon@gmail.com>,
Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Subject: Re: [PATCH v8 0/8] Rewrite `git_config()` using config-set API
Date: Fri, 08 Aug 2014 19:37:02 +0530 [thread overview]
Message-ID: <53E4D986.6040708@gmail.com> (raw)
In-Reply-To: <xmqqoavwjb3i.fsf@gitster.dls.corp.google.com>
On 8/8/2014 2:01 AM, Junio C Hamano wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>>>> Why is this needed? Are you now using key_value_info outside config.c?
>>>> Or is it a leftover from a previous experiment?
>>>
>>> Has this been resolved in the new round?
>>
>> Tanay explained in another subthread why this was needed. For callers
>> iterating over the string_list who want to get the file/line info, they
>> need to be able to cast the void * pointer to struct key_value_info *.
>
> For callers that want to see all the multi-values, it would be
> preferrable for the iterator to pass the filename and the linenumber
> to the callback function, instead of exposing its implementation
> detail as a single string list and telling them to pick it apart,
> no?
>
> Not a very convincing argument, but OK for now in the sense that we
> can fix it later if we wanted to before it gets too late.
>
(cc to Ramsay)
The discussion in both threads (v8 and v9), boils down to this,
is the `key_value_info` struct really required to be declared public or should be
just an implementation detail. I will give you the context,
The usage of the above mentioned struct is only required for
git_config_get_value_multi(). With the public struct, the code flow would look
like,
-- 8< --
diff --git a/notes.c b/notes.c
index 5fe691d..b7ab115 100644
--- a/notes.c
+++ b/notes.c
@@ -961,19 +961,6 @@ void string_list_add_refs_from_colon_sep(struct string_list *list,
free(globs_copy);
}
-static int notes_display_config(const char *k, const char *v, void *cb)
-{
- int *load_refs = cb;
-
- if (*load_refs && !strcmp(k, "notes.displayref")) {
- if (!v)
- config_error_nonbool(k);
- string_list_add_refs_by_glob(&display_notes_refs, v);
- }
-
- return 0;
-}
-
const char *default_notes_ref(void)
{
const char *notes_ref = NULL;
@@ -1041,7 +1028,9 @@ struct notes_tree **load_notes_trees(struct string_list *refs)
void init_display_notes(struct display_notes_opt *opt)
{
char *display_ref_env;
- int load_config_refs = 0;
+ const struct string_list *values;
+ struct key_value_info *kv_info;
+ int load_config_refs = 0, i;
display_notes_refs.strdup_strings = 1;
assert(!display_notes_trees);
@@ -1058,7 +1047,21 @@ void init_display_notes(struct display_notes_opt *opt)
load_config_refs = 1;
}
- git_config(notes_display_config, &load_config_refs);
+ if (load_config_refs) {
+ values = git_config_get_value_multi("notes.displayref");
+ if (values) {
+ for (i = 0; i < values->nr; i++) {
+ if (!values->items[i].string) {
+ kv_info = values->items[i].util;
+ config_error_nonbool("notes.displayref");
+ git_die_config_linenr("notes.displayref", kv_info->filename, kv_info->linenr);
+ }
+ else
+ string_list_add_refs_by_glob(&display_notes_refs,
+ values->items[i].string);
+ }
+ }
+ }
if (opt) {
struct string_list_item *item;
-- 8< --
We cannot use git_die_config() here because it is applicable to the last
value for a given variable.
Alternative solution to the problem can be a helper function like this,
git_die_config_index(key, value_index, err_msg, ...) which needs the value_index for a multi valued one,
+ values = git_config_get_value_multi("notes.displayref");
+ if (values) {
+ for (i = 0; i < values->nr; i++) {
+ if (!values->items[i].string)
+ git_die_config_linenr("notes.displayref", i, "no null values allowed for :'%s'", "notes.displayref");
+ else ; /* do stuff */
+ }
A callback iterator which supplies the linenr and filename to the callback
function is not helpful, because there are many variable checks in a
git_config() call where multi valued and single valued both reside, so we cannot
use a callback iterator without adding more code cruft.
What do you think, which way seems least obtrusive, or is there an another way out?
next prev parent reply other threads:[~2014-08-08 14:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-06 14:53 [PATCH v8 0/8] Rewrite `git_config()` using config-set API Tanay Abhra
2014-08-06 14:53 ` [PATCH v8 1/8] config.c: mark error and warnings strings for translation Tanay Abhra
2014-08-06 14:53 ` [PATCH v8 2/8] config.c: fix accuracy of line number in errors Tanay Abhra
2014-08-06 14:53 ` [PATCH v8 3/8] add line number and file name info to `config_set` Tanay Abhra
2014-08-06 15:49 ` Ramsay Jones
2014-08-06 14:53 ` [PATCH v8 4/8] change `git_config()` return value to void Tanay Abhra
2014-08-06 14:53 ` [PATCH v8 5/8] config: add `git_die_config()` to the config-set API Tanay Abhra
2014-08-06 14:53 ` [PATCH v8 6/8] rewrite git_config() to use " Tanay Abhra
2014-08-06 14:53 ` [PATCH v8 7/8] add a test for semantic errors in config files Tanay Abhra
2014-08-06 14:53 ` [PATCH v8 8/8] add tests for `git_config_get_string_const()` Tanay Abhra
2014-08-06 15:32 ` Matthieu Moy
2014-08-06 15:44 ` Tanay Abhra
2014-08-06 21:22 ` Junio C Hamano
2014-08-07 8:30 ` Matthieu Moy
2014-08-06 15:26 ` [PATCH v8 0/8] Rewrite `git_config()` using config-set API Matthieu Moy
2014-08-07 19:03 ` Junio C Hamano
2014-08-07 19:35 ` Matthieu Moy
2014-08-07 20:31 ` Junio C Hamano
2014-08-08 14:07 ` Tanay Abhra [this message]
2014-08-08 14:32 ` Ramsay Jones
2014-08-10 17:29 ` Junio C Hamano
2014-08-11 9:59 ` Ramsay Jones
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=53E4D986.6040708@gmail.com \
--to=tanayabh@gmail.com \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ramsay@ramsay1.demon.co.uk \
/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).