git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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?

  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).