git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [WIP/PATCH v4 6/8] for-each-ref: rename some functions and make them public

From
Karthik Nayak <karthik.188@gmail.com>
Date
Jun 1, 2015, 19:35 UTC
Message-ID
<C9DFEB12-F48F-4F73-AFC8-F37892C75A92@gmail.com>
In-Reply-To
<xmqqvbf78oow.fsf@gitster.dls.corp.google.com>
On June 1, 2015 8:23:51 PM GMT+05:30, Junio C Hamano <gitster@pobox.com> wrote:
Show 19 quoted lines
>Karthik Nayak <karthik.188@gmail.com> writes:
>
>> Could be achieved using a simple wrapper around 'filter_refs()'
>> something like this perhaps.
>>
>> int filter_refs_with_pattern(struct ref_array *ref, int
>> (*for_each_ref_fn)(each_ref_fn, void *), char **patterns)
>> {
>> 	int i;
>> 	struct ref_filter_cbdata data;
>> 	data.filter.name_patterns = patterns;
>> 	filter_refs(for_each_ref_fn, &data);
>
>I presume that this is
>
>	filter_refs(&refs, for_each_ref_fn, &data);
>
>as you would need to have some way to get the result back ;-)
>
No it's meant to be that way, see as it takes a struct ref_filter_cbdata, the filters are put in the data.filter.* and we obtain the refs in the data.array.items. So no need for another ref_array to hold the array of items.
Show 39 quoted lines
>> 	refs->nr = data.array.nr;
>> 	for(i = 0; i < refs->nr; i++) {
>> 		/* copy over the refs */
>> 	}
>> 	return 0;
>> }
>>
>> Is this on the lines of what you had in mind? If it is, than I could
>> just create a new patch which would make ref_filter_handler() private
>> and introduce filter_refs() as shown.
>
>Yeah.  Even though I suggested
>
>	filter_refs(&for_each_ref, ...);
>
>I actually would think the external interface should not mention
>for_each_ref() like I did.  The primary reason why I felt that it is
>bad for the API to export a generic callback function the caller can
>use to call for_each_ref() or for_each_rawref()" in the longer term
>is because it forces us to always iterate all refs; for_each_ref()
>does not know what the callback filter function wants to do.  The
>most common way to filter in the context of your GSoC project is "we
>limit only to refs/heads/*, and then we may also filter by other
>criteria" (that is "git branch" "-l" or possibly with "--contains",
>etc.), and it is very wasteful for that codepath to allow
>for_each_ref() to even enumerate and feed all refs outside the
>refs/heads/* area to your callback, which would involve reading all
>entries in packed-refs (which is a fixed cost so not an overhead)
>and then reading everything in .git/refs/* (which is an overhead we
>could and should avoid when we know we are only interested in the
>branches that live in refs/heads*).
>
>Your first implementation of course can just call for_each_ref() or
>for_each_rawref(), and at the end of GSoC, the code may still do so.
>But by keeping the external interface free of for_each_ref(), you
>could later optimize.
>
>And your above sample only takes for_each_ref_fn without exposing the
>internal use of for_each_ref(), which is good.
That seems good, thanks for the guidance.
Previous: Junio C HamanoNext: Karthik Nayak
Message 32 of 44 in “for-each-ref: extract helper functions out of grab_single_ref()”
  1. 1/8 for-each-ref: extract helper functions out of grab_single_ref()Karthik Nayak, May 30, 2015
  2. Eric SunshineMay 31, 2015
  3. Karthik NayakMay 31, 2015
  4. Junio C HamanoMay 31, 2015
  5. Karthik NayakMay 31, 2015
  6. Matthieu MoyMay 31, 2015
  7. Junio C HamanoJun 1, 2015
  8. 2/8 for-each-ref: simplify codeKarthik Nayak, May 30, 2015
  9. 3/8 for-each-ref: rename 'refinfo' to 'ref_array_item'Karthik Nayak, May 30, 2015
  10. Junio C HamanoMay 31, 2015
  11. Karthik NayakMay 31, 2015
  12. 4/8 for-each-ref: introduce new structures for better organisationKarthik Nayak, May 30, 2015
  13. Eric SunshineMay 31, 2015
  14. Karthik NayakMay 31, 2015
  15. 5/8 for-each-ref: introduce 'ref_filter_clear_data()'Karthik Nayak, May 30, 2015
  16. Christian CouderMay 31, 2015
  17. Karthik NayakMay 31, 2015
  18. 6/8 for-each-ref: rename some functions and make them publicKarthik Nayak, May 30, 2015
  19. Eric SunshineMay 31, 2015
  20. Karthik NayakMay 31, 2015
  21. Christian CouderMay 31, 2015
  22. Christian CouderMay 31, 2015
  23. Karthik NayakMay 31, 2015
  24. Christian CouderMay 31, 2015
  25. Karthik NayakMay 31, 2015
  26. Matthieu MoyJun 1, 2015
  27. Karthik NayakJun 1, 2015
  28. Junio C HamanoMay 31, 2015
  29. Junio C HamanoMay 31, 2015
  30. Karthik NayakMay 31, 2015
  31. Junio C HamanoJun 1, 2015
  32. Karthik NayakJun 1, 2015
  33. 7/8 ref-filter: move code from 'for-each-ref'Karthik Nayak, May 30, 2015
  34. 8/8 ref-filter: add 'ref-filter.h'Karthik Nayak, May 30, 2015
  35. Eric SunshineMay 31, 2015
  36. Karthik NayakMay 31, 2015
  37. Eric SunshineMay 31, 2015
  38. Karthik NayakMay 31, 2015
  39. Matthieu MoyMay 31, 2015
  40. Karthik NayakMay 31, 2015
  41. Christian CouderMay 31, 2015
  42. Matthieu MoyJun 1, 2015
  43. Christian CouderMay 31, 2015
  44. Karthik NayakMay 31, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.