Re: [PATCH 3/7] submodule-config: keep labels around

2016-05-11 Thread Stefan Beller
+Heiko

On Wed, May 11, 2016 at 2:28 PM, Junio C Hamano  wrote:
> 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

2016-05-11 Thread Junio C Hamano
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.
--
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

2016-05-11 Thread Stefan Beller
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).
--
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

2016-05-10 Thread Junio C Hamano
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.

> @@ -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

2016-05-10 Thread Stefan Beller
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