Re: [PATCH 3/7] submodule-config: keep labels around
+Heiko On Wed, May 11, 2016 at 2:28 PM, Junio C Hamanowrote: > Stefan Beller writes: > >> On Tue, May 10, 2016 at 6:15 PM, Junio C Hamano wrote: >>> Stefan Beller writes: >>> @@ -199,6 +203,7 @@ static struct submodule *lookup_or_create_by_name(struct submodule_cache *cache, submodule->update_strategy.command = NULL; submodule->fetch_recurse = RECURSE_SUBMODULES_NONE; submodule->ignore = NULL; + submodule->labels = NULL; >>> >>> Hmph, is there a reason to do this, instead of embedding an instance >>> of "struct string_list" inside submodule structure? >>> >>> I am not yet claiming that embedding is better. Just wondering if >>> it makes it easier to handle initialization as seen in the hunk >>> below, and also _clear() procedure. >> >> Thanks for pointing out that alternative. That looks so much >> better in this patch. Let's see how the follow up patches develop. >> As we'd not check != NULL first, but check against the count of the >> string list. (I expect no problems down that road though). > > I also wonder if we can say the same for the .ignore field, by the > way, if we agree that it is a better direction to go. I don't think this is a good idea, as it's just a string, like .{url, name, path} Instead of storing the string we could store an enum {UNTRACKED, DIRTY, ALL, NONE, NOT_INIT} though. That would be better I guess. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] submodule-config: keep labels around
Stefan Bellerwrites: > On Tue, May 10, 2016 at 6:15 PM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> @@ -199,6 +203,7 @@ static struct submodule >>> *lookup_or_create_by_name(struct submodule_cache *cache, >>> submodule->update_strategy.command = NULL; >>> submodule->fetch_recurse = RECURSE_SUBMODULES_NONE; >>> submodule->ignore = NULL; >>> + submodule->labels = NULL; >> >> Hmph, is there a reason to do this, instead of embedding an instance >> of "struct string_list" inside submodule structure? >> >> I am not yet claiming that embedding is better. Just wondering if >> it makes it easier to handle initialization as seen in the hunk >> below, and also _clear() procedure. > > Thanks for pointing out that alternative. That looks so much > better in this patch. Let's see how the follow up patches develop. > As we'd not check != NULL first, but check against the count of the > string list. (I expect no problems down that road though). I also wonder if we can say the same for the .ignore field, by the way, if we agree that it is a better direction to go. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] submodule-config: keep labels around
On Tue, May 10, 2016 at 6:15 PM, Junio C Hamanowrote: > Stefan Beller writes: > >> @@ -199,6 +203,7 @@ static struct submodule *lookup_or_create_by_name(struct >> submodule_cache *cache, >> submodule->update_strategy.command = NULL; >> submodule->fetch_recurse = RECURSE_SUBMODULES_NONE; >> submodule->ignore = NULL; >> + submodule->labels = NULL; > > Hmph, is there a reason to do this, instead of embedding an instance > of "struct string_list" inside submodule structure? > > I am not yet claiming that embedding is better. Just wondering if > it makes it easier to handle initialization as seen in the hunk > below, and also _clear() procedure. Thanks for pointing out that alternative. That looks so much better in this patch. Let's see how the follow up patches develop. As we'd not check != NULL first, but check against the count of the string list. (I expect no problems down that road though). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] submodule-config: keep labels around
Stefan Bellerwrites: > @@ -199,6 +203,7 @@ static struct submodule *lookup_or_create_by_name(struct > submodule_cache *cache, > submodule->update_strategy.command = NULL; > submodule->fetch_recurse = RECURSE_SUBMODULES_NONE; > submodule->ignore = NULL; > + submodule->labels = NULL; Hmph, is there a reason to do this, instead of embedding an instance of "struct string_list" inside submodule structure? I am not yet claiming that embedding is better. Just wondering if it makes it easier to handle initialization as seen in the hunk below, and also _clear() procedure. > @@ -353,6 +358,17 @@ static int parse_config(const char *var, const char > *value, void *data) > else if (parse_submodule_update_strategy(value, >>update_strategy) < 0) > die(_("invalid value for %s"), var); > + } else if (!strcmp(item.buf, "label")) { > + if (!value) > + ret = config_error_nonbool(var); > + else { > + if (!submodule->labels) { > + submodule->labels = > + xmalloc(sizeof(*submodule->labels)); > + string_list_init(submodule->labels, 1); > + } > + string_list_insert(submodule->labels, value); > + } > } -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] submodule-config: keep labels around
We need the submodule labels in a later patch. Signed-off-by: Stefan Beller--- submodule-config.c | 16 submodule-config.h | 2 ++ 2 files changed, 18 insertions(+) diff --git a/submodule-config.c b/submodule-config.c index b82d1fb..0cdb47e 100644 --- a/submodule-config.c +++ b/submodule-config.c @@ -60,6 +60,10 @@ static void free_one_config(struct submodule_entry *entry) free((void *) entry->config->path); free((void *) entry->config->name); free((void *) entry->config->update_strategy.command); + if (entry->config->labels) { + string_list_clear(entry->config->labels, 0); + free(entry->config->labels); + } free(entry->config); } @@ -199,6 +203,7 @@ static struct submodule *lookup_or_create_by_name(struct submodule_cache *cache, submodule->update_strategy.command = NULL; submodule->fetch_recurse = RECURSE_SUBMODULES_NONE; submodule->ignore = NULL; + submodule->labels = NULL; hashcpy(submodule->gitmodules_sha1, gitmodules_sha1); @@ -353,6 +358,17 @@ static int parse_config(const char *var, const char *value, void *data) else if (parse_submodule_update_strategy(value, >update_strategy) < 0) die(_("invalid value for %s"), var); + } else if (!strcmp(item.buf, "label")) { + if (!value) + ret = config_error_nonbool(var); + else { + if (!submodule->labels) { + submodule->labels = + xmalloc(sizeof(*submodule->labels)); + string_list_init(submodule->labels, 1); + } + string_list_insert(submodule->labels, value); + } } strbuf_release(); diff --git a/submodule-config.h b/submodule-config.h index e4857f5..d57da59 100644 --- a/submodule-config.h +++ b/submodule-config.h @@ -18,6 +18,8 @@ struct submodule { struct submodule_update_strategy update_strategy; /* the sha1 blob id of the responsible .gitmodules file */ unsigned char gitmodules_sha1[20]; + /* sorted, not as on disk */ + struct string_list *labels; }; int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg); -- 2.8.0.35.g58985d9.dirty -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html