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

Re: [PATCH v13 05/12] ref-filter: add option to filter out tags, branches and remotes

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Aug 27, 2015, 15:24 UTC
Message-ID
<55DF2BA1.2020107@alum.mit.edu>
In-Reply-To
<CAOLa=ZQh0MNwjAOLameh1f22LB=JyD7=FeROzDRikpoRXse7cw@mail.gmail.com>
On 08/27/2015 02:42 PM, Karthik Nayak wrote:
Show 27 quoted lines
> On Wed, Aug 26, 2015 at 9:40 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> On 08/22/2015 05:39 AM, Karthik Nayak wrote:
>>> [...]
>>> +     if (type == FILTER_REFS_BRANCHES)
>>> +             ret = for_each_reftype_fullpath(ref_filter_handler, "refs/heads/", broken, &ref_cbdata);
>>> +     else if (type == FILTER_REFS_REMOTES)
>>> +             ret = for_each_reftype_fullpath(ref_filter_handler, "refs/remotes/", broken, &ref_cbdata);
>>> +     else if (type == FILTER_REFS_TAGS)
>>> +             ret = for_each_reftype_fullpath(ref_filter_handler, "refs/tags/", broken, &ref_cbdata);
>>> +     else if (type & FILTER_REFS_ALL) {
>>> +             ret = for_each_reftype_fullpath(ref_filter_handler, "", broken, &ref_cbdata);
>>> +             if (type & FILTER_REFS_DETACHED_HEAD)
>>> +                     head_ref(ref_filter_handler, &ref_cbdata);
>>
>> The usual promise of the for_each_ref functions is that they stop
>> iterating if the function ever returns a nonzero value. So the above
>> should be
>>
>>                 if (! ret && (type & FILTER_REFS_DETACHED_HEAD))
>>                         ret = head_ref(ref_filter_handler, &ref_cbdata);
>>
>> Also, these functions usually iterate in lexicographic order, so I think
>> you should process HEAD before the others.
> 
> This is done on purpose, cause we need to print the HEAD ref separately
> so we print the last ref_array_item in the ref_array, free that memory and
> sort and print the rest, hence HEAD ref is attached to the last.

Without having looked at the other patches, this makes me wonder whether it makes sense to store HEAD in the ref_array at all or whether it should be handled separately.

Show 37 quoted lines
>> But there's another problem here. It seems like
>> FILTER_REFS_DETACHED_HEAD is only processed if (type & FILTER_REFS_ALL)
>> is nonzero. But shouldn't it be allowed to process *only* HEAD?
>>
>> So, finally, I think this code should look like
>>
>>         else if (!filter->kind)
>>                 die("filter_refs: invalid type");
>>         else {
>>                 if (filter->kind & FILTER_REFS_DETACHED_HEAD)
>>                         ret = head_ref(ref_filter_handler, &ref_cbdata);
>>                 if (! ret && (filter->kind & FILTER_REFS_ALL))
>>                         ret =
>> for_each_reftype_fullpath(ref_filter_handler, "", broken, &ref_cbdata);
>>         }
>>
> 
> So finally something like this perhaps
> 
>     if (!filter->kind)
>         die("filter_refs: invalid type");
>     else {
>         if (filter->kind == FILTER_REFS_BRANCHES)
>             ret = for_each_reftype_fullpath(ref_filter_handler,
> "refs/heads/", broken, &ref_cbdata);
>         else if (filter->kind == FILTER_REFS_REMOTES)
>             ret = for_each_reftype_fullpath(ref_filter_handler,
> "refs/remotes/", broken, &ref_cbdata);
>         else if (filter->kind == FILTER_REFS_TAGS)
>             ret = for_each_reftype_fullpath(ref_filter_handler,
> "refs/tags/", broken, &ref_cbdata);
>         else if (filter->kind & FILTER_REFS_ALL)
>             ret = for_each_reftype_fullpath(ref_filter_handler, "",
> broken, &ref_cbdata);
>         if (filter->kind & FILTER_REFS_DETACHED_HEAD)
>             head_ref(ref_filter_handler, &ref_cbdata);
>     }
Yes, but the last test should be
        if (!ret && (filter->kind & FILTER_REFS_DETACHED_HEAD))

unless you have a reason not to follow the usual convention that a nonzero return value from fn means that the iteration should be aborted.

Michael
-- 
Michael Haggerty
mhagger@alum.mit.edu
Previous: Karthik NayakNext: Karthik Nayak
Message 22 of 60 in “port tag.c to use ref-filter APIs”
  1. 00/12 port tag.c to use ref-filter APIsKarthik Nayak, Aug 22, 2015
  2. 01/12 ref-filter: move `struct atom_value` to ref-filter.cKarthik Nayak, Aug 22, 2015
  3. 02/12 ref-filter: introduce ref_formatting_state and ref_formatting_stackKarthik Nayak, Aug 22, 2015
  4. Junio C HamanoAug 24, 2015
  5. Karthik NayakAug 25, 2015
  6. 03/12 utf8: add function to align a string into given strbufKarthik Nayak, Aug 22, 2015
  7. 04/12 ref-filter: implement an `align` atomKarthik Nayak, Aug 22, 2015
  8. Junio C HamanoAug 24, 2015
  9. Junio C HamanoAug 24, 2015
  10. Karthik NayakAug 25, 2015
  11. Matthieu MoyAug 25, 2015
  12. Karthik NayakAug 25, 2015
  13. Junio C HamanoAug 25, 2015
  14. Karthik NayakAug 26, 2015
  15. Junio C HamanoAug 25, 2015
  16. Karthik NayakAug 25, 2015
  17. 05/12 ref-filter: add option to filter out tags, branches and remotesKarthik Nayak, Aug 22, 2015
  18. Junio C HamanoAug 24, 2015
  19. Karthik NayakAug 25, 2015
  20. Michael HaggertyAug 26, 2015
  21. Karthik NayakAug 27, 2015
  22. Michael HaggertyAug 27, 2015
  23. Karthik NayakAug 27, 2015
  24. 06/12 ref-filter: support printing N lines from tag annotationKarthik Nayak, Aug 22, 2015
  25. 07/12 ref-filter: add support to sort by versionKarthik Nayak, Aug 22, 2015
  26. 08/12 ref-filter: add option to match literal patternKarthik Nayak, Aug 22, 2015
  27. 09/12 tag.c: use 'ref-filter' data structuresKarthik Nayak, Aug 22, 2015
  28. 10/12 tag.c: use 'ref-filter' APIsKarthik Nayak, Aug 22, 2015
  29. 11/12 tag.c: implement '--format' optionKarthik Nayak, Aug 22, 2015
  30. Matthieu MoyAug 23, 2015
  31. Karthik NayakAug 24, 2015
  32. Matthieu MoyAug 24, 2015
  33. Karthik NayakAug 24, 2015
  34. 12/12 tag.c: implement '--merged' and '--no-merged' optionsKarthik Nayak, Aug 22, 2015
  35. Matthieu MoyAug 23, 2015
  36. Karthik NayakAug 24, 2015
  37. Matthieu MoyAug 24, 2015
  38. Karthik NayakAug 24, 2015
  39. Junio C HamanoAug 24, 2015
  40. Junio C HamanoAug 24, 2015
  41. Karthik NayakAug 25, 2015
  42. Junio C HamanoAug 25, 2015
  43. Junio C HamanoAug 25, 2015
  44. Karthik NayakAug 26, 2015
  45. Junio C HamanoAug 26, 2015
  46. Karthik NayakAug 26, 2015
  47. Junio C HamanoAug 26, 2015
  48. Karthik NayakAug 27, 2015
  49. Karthik NayakAug 25, 2015
  50. Junio C HamanoAug 24, 2015
  51. Karthik NayakAug 24, 2015
  52. Junio C HamanoAug 24, 2015
  53. Junio C HamanoAug 24, 2015
  54. Karthik NayakAug 26, 2015
  55. Matthieu MoyAug 26, 2015
  56. Junio C HamanoAug 26, 2015
  57. Junio C HamanoAug 26, 2015
  58. Matthieu MoyAug 26, 2015
  59. Karthik NayakAug 26, 2015
  60. Karthik NayakAug 25, 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.