On Tue, Jul 28, 2015 at 7:18 PM, Matthieu Moy
<[email protected]> wrote:
> Christian Couder <[email protected]> writes:
>
>> On Tue, Jul 28, 2015 at 8:56 AM, Karthik Nayak <[email protected]> wrote:
>>
>>> +static void ref_array_append(struct ref_array *array, const char *refname)
>>> +{
>>> + size_t len = strlen(refname);
>>> + struct ref_array_item *ref = xcalloc(1, sizeof(struct
>>> ref_array_item) + len + 1);
>>> + memcpy(ref->refname, refname, len);
>>> + ref->refname[len] = '\0';
>
> This looks very much like new_ref_array_item, except that the later also
> takes an objectname parameter. I find it suspicious that you leave the
> objectname field uninitialized.
>
Well the objectname is not required here, the idea is to retain the way branch.c
works.
> Why is this code not calling new_ref_array_item?
>
Because no objectname is there.
> A detail: you could return a pointer to the newly allocated object to
> write
>
> item = ref_array_append(array, refname);
>
> instead of
>
> ref_array_append(array, refname);
> item = array->items[array->nr - 1];
>
Yeah doing that :)
>>> + REALLOC_ARRAY(array->items, array->nr + 1);
>>> + array->items[array->nr++] = ref;
>>> +}
>>
>> This function belongs more to ref-filter.{c,h}...
>
> The function disapears in the next commit, but I also think that this
> function deserves to exist in ref-filter.{c,h} and remain after the end
> of the series.
>
Why though? I don't see the need when new_ref_array_item() is present.
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
