Re: [PATCH v14 2/4] ref-filter: make ref_array_item allocation more consistent

[Junio C Hamano]

Eric Sunshine  writes:

> On Wed, Apr 11, 2018 at 2:07 PM, Stefan Beller  wrote:
>> On Wed, Apr 11, 2018 at 10:57 AM, Harald Nordgren
>>  wrote:
>>> There have been no new comments for the last few days. I know Jeff
>>> King will be away for the next two weeks, but should we still move
>>> forward with this? The initial reactions to the idea seemed positive.
>> ...
>> It will be merged to next and if no people speak up (due to bugs
>> observed or such)
>
> I would guess, however, that Harald is wondering more specifically
> about the "--sort" patch he added atop Peff's patches. Disposition for
> _that_ patch is not specified in the latest "What's cooking":
>
> * hn/sort-ls-remote (2018-04-09) 1 commit
>  - ls-remote: create '--sort' option
>  (this branch uses jk/ref-array-push.)
>
>  "git ls-remote" learned an option to allow sorting its output based
>  on the refnames being shown.

Thanks all for summarizing.

I think the preliminary clean-up patches by Peff are all
independently good and can be advanced, even without him being
around.  I haven't formed a firm opinion on the doneness of the
latest round of the "--sort" thing.  I usually do not explicitly
write "I haven't formed an opinion" in "What's cooking" report,
so please read the lack of "disposition" as such.

Re: [PATCH v14 2/4] ref-filter: make ref_array_item allocation more consistent

[Eric Sunshine]

On Wed, Apr 11, 2018 at 2:07 PM, Stefan Beller  wrote:
> On Wed, Apr 11, 2018 at 10:57 AM, Harald Nordgren
>  wrote:
>> There have been no new comments for the last few days. I know Jeff
>> King will be away for the next two weeks, but should we still move
>> forward with this? The initial reactions to the idea seemed positive.
>
> Please see the "What's cooking?" email on the mailing list that is
> sent out periodically by Junio.
>
>> * jk/ref-array-push (2018-04-09) 3 commits
>> - ref-filter: factor ref_array pushing into its own function
>> - ref-filter: make ref_array_item allocation more consistent
>> - ref-filter: use "struct object_id" consistently
>> (this branch is used by hn/sort-ls-remote.)
>>
>> API clean-up aournd ref-filter code.
>>
>> Will merge to 'next'.
>
> It will be merged to next and if no people speak up (due to bugs
> observed or such)

I would guess, however, that Harald is wondering more specifically
about the "--sort" patch he added atop Peff's patches. Disposition for
_that_ patch is not specified in the latest "What's cooking":

* hn/sort-ls-remote (2018-04-09) 1 commit
 - ls-remote: create '--sort' option
 (this branch uses jk/ref-array-push.)

 "git ls-remote" learned an option to allow sorting its output based
 on the refnames being shown.

Re: [PATCH v14 2/4] ref-filter: make ref_array_item allocation more consistent

[Todd Zullinger]

Hi Stefan,

Stefan Beller wrote:
> Please see the "What's cooking?" email on the mailing list that is
> sent out periodically by Junio.
> the last one is
> https://public-inbox.org/git/xmqqd0z865pk@gitster-ct.c.googlers.com/
> which says:
> 
>> * jk/ref-array-push (2018-04-09) 3 commits
>> - ref-filter: factor ref_array pushing into its own function
>> - ref-filter: make ref_array_item allocation more consistent
>> - ref-filter: use "struct object_id" consistently
>> (this branch is used by hn/sort-ls-remote.)
>>
>> API clean-up aournd ref-filter code.
>>
>> Will merge to 'next'.
> 
> It will be merged to next and if no people speak up (due to bugs
> observed or such)
> then it will be merged to master eventually, later.
> 
> I am not able to find the documentation for the workflow right now,
> though it is partially covered in Documentation/SubmittingPatches.

Perhaps Documentation/howto/maintain-git.txt is the
documentation you're thinking of?

https://kernel.org/pub/software/scm/git/docs/howto/maintain-git.html

There's also MaintNotes in the todo branch:

https://raw.githubusercontent.com/git/git/todo/MaintNotes

-- 
Todd
~~
Be who you are and say what you feel because those who mind don't
matter and those who matter don't mind.
-- Dr Seuss, "Oh the Places You'll Go"

Re: [PATCH v14 2/4] ref-filter: make ref_array_item allocation more consistent

[Stefan Beller]

Hi Harald,

On Wed, Apr 11, 2018 at 10:57 AM, Harald Nordgren
 wrote:
> There have been no new comments for the last few days. I know Jeff
> King will be away for the next two weeks, but should we still move
> forward with this? The initial reactions to the idea seemed positive.

Please see the "What's cooking?" email on the mailing list that is
sent out periodically by Junio.
the last one is
https://public-inbox.org/git/xmqqd0z865pk@gitster-ct.c.googlers.com/
which says:

> * jk/ref-array-push (2018-04-09) 3 commits
> - ref-filter: factor ref_array pushing into its own function
> - ref-filter: make ref_array_item allocation more consistent
> - ref-filter: use "struct object_id" consistently
> (this branch is used by hn/sort-ls-remote.)
>
> API clean-up aournd ref-filter code.
>
> Will merge to 'next'.

It will be merged to next and if no people speak up (due to bugs
observed or such)
then it will be merged to master eventually, later.

I am not able to find the documentation for the workflow right now,
though it is partially covered in Documentation/SubmittingPatches.

Re: [PATCH v14 2/4] ref-filter: make ref_array_item allocation more consistent

[Harald Nordgren]

There have been no new comments for the last few days. I know Jeff
King will be away for the next two weeks, but should we still move
forward with this? The initial reactions to the idea seemed positive.

Best regards
Harald

On Mon, Apr 9, 2018 at 3:42 AM, Harald Nordgren
 wrote:
> From: Jeff King 
>
> We have a helper function to allocate ref_array_item
> structs, but it only takes a subset of the possible fields
> in the struct as initializers. We could have it accept an
> argument for _every_ field, but that becomes a pain for the
> fields which some callers don't want to set initially.
>
> Instead, let's be explicit that it takes only the minimum
> required to create the ref, and that callers should then
> fill in the rest themselves.
>
> Signed-off-by: Jeff King 
> Signed-off-by: Harald Nordgren 
> ---
>  ref-filter.c | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/ref-filter.c b/ref-filter.c
> index ade97a848..c1c3cc948 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -1824,15 +1824,18 @@ static const struct object_id *match_points_at(struct 
> oid_array *points_at,
> return NULL;
>  }
>
> -/* Allocate space for a new ref_array_item and copy the objectname and flag 
> to it */
> +/*
> + * Allocate space for a new ref_array_item and copy the name and oid to it.
> + *
> + * Callers can then fill in other struct members at their leisure.
> + */
>  static struct ref_array_item *new_ref_array_item(const char *refname,
> -const struct object_id *oid,
> -int flag)
> +const struct object_id *oid)
>  {
> struct ref_array_item *ref;
> +
> FLEX_ALLOC_STR(ref, refname, refname);
> oidcpy(>objectname, oid);
> -   ref->flag = flag;
>
> return ref;
>  }
> @@ -1927,12 +1930,13 @@ static int ref_filter_handler(const char *refname, 
> const struct object_id *oid,
>  * to do its job and the resulting list may yet to be pruned
>  * by maxcount logic.
>  */
> -   ref = new_ref_array_item(refname, oid, flag);
> +   ref = new_ref_array_item(refname, oid);
> ref->commit = commit;
> +   ref->flag = flag;
> +   ref->kind = kind;
>
> REALLOC_ARRAY(ref_cbdata->array->items, ref_cbdata->array->nr + 1);
> ref_cbdata->array->items[ref_cbdata->array->nr++] = ref;
> -   ref->kind = kind;
> return 0;
>  }
>
> @@ -2169,7 +2173,7 @@ void pretty_print_ref(const char *name, const struct 
> object_id *oid,
>   const struct ref_format *format)
>  {
> struct ref_array_item *ref_item;
> -   ref_item = new_ref_array_item(name, oid, 0);
> +   ref_item = new_ref_array_item(name, oid);
> ref_item->kind = ref_kind_from_refname(name);
> show_ref_array_item(ref_item, format);
> free_array_item(ref_item);
> --
> 2.14.3 (Apple Git-98)
>