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

Re: [PATCH 1/2] ref-filter: hacky "streaming" mode

From
ZheNing Hu <adlternative@gmail.com>
Date
Sep 7, 2021, 05:28 UTC
Message-ID
<CAOLTT8QbdNBSY95bCa+UNJBqsJEEHbnaKfZLzvN2Qzd-Np8Lqg@mail.gmail.com>
In-Reply-To
<YTTARcEvpXWSDfYW@coredump.intra.peff.net>
Jeff King <peff@peff.net> 于2021年9月5日周日 下午9:04写道:
Show 36 quoted lines
>
> On Sun, Sep 05, 2021 at 04:20:02PM +0800, ZheNing Hu wrote:
>
> > But here is a terrible fact: we did not use ref_array_sort() for sorting here.
> > So in fact, for_each_fullref_in() does the sorting work () for us by
> > default sort (%(refname)),
> > This may be due to the file system or some implementation of ref_iterator.
> > But this limit the application of this optimization when we use other
> > atoms to sort.
>
> Right. This technique does not help at all if you use --sort. I do think
> it's reasonable to rely on the sorted output of the for_each_ref()
> functions; other parts of Git likely do as well, so I think we'd try
> pretty hard to maintain that (and no, it's not a filesystem thing; we do
> make sure to sort it ourselves; see the calls to sort_ref_dir()).
>
> > > +       /*
> > > +        * the %(symref) placeholder is broken with pretty_print_ref(),
> > > +        * which our streaming code uses. I suspect this is a sign of breakage
> > > +        * in other callers like verify_tag(), which should be fixed. But for
> > > +        * now just disable streaming.
> > > +        *
> > > +        * Note that this implies we've parsed the format already with
> > > +        * verify_ref_format().
> > > +        */
> > > +       if (need_symref)
> > > +               return;
> > > +
> >
> > I haven’t taken a closer look at why pretty_print_ref() does not
> > support %(symref),
> > we can skip it first.
>
> I think it's just because pretty_print_ref() does not take a "flag"
> parameter for the caller. So it never sees that REF_ISSYMREF is set.
>

yeah, pretty_print_ref() does not set the flag, this is a defect of pretty_print_ref(), maybe we need to find a way to set this flag. I also deliberately avoided %(symref) when refactoring git cat-file --batch, perhaps the improvements here can also be applied to git cat-file --batch

Show 21 quoted lines
> There aren't many callers of that function, so I think nobody ever
> really noticed. But you can see the bug like this:
>
>   git init repo
>   cd repo
>
>   git commit --allow-empty -m foo
>   git tag -s -m bar annotated &&
>   git symbolic-ref refs/tags/symref refs/tags/annotated
>
>   # this is ok; ref-filter handles the flags
>   git tag --list --format='list: %(refname) %(symref)'
>
>   # not ok; we do not tell the formatter about the flags, so it does
>   # not notice that "symref" is a symref
>   git tag --verify --format='verify: %(refname) %(symref)' annotated symref
>
> I notice that the --verify output also shows the short refname, which
> makes me wonder if %(symref) would have other bugs there (because it
> has to re-resolve the ref to come up with the symref destination).
>
This may be easy to fix:
diff --git a/builtin/tag.c b/builtin/tag.c
index 452558ec95..4be5d36366 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -152,11 +152,11 @@ static int verify_tag(const char *name, const char *ref,
        if (format->format)
                flags = GPG_VERIFY_OMIT_STATUS;

-       if (gpg_verify_tag(oid, name, flags))
+       if (gpg_verify_tag(oid, ref, flags))
                return -1;

        if (format->format)
-               pretty_print_ref(name, oid, format);
+               pretty_print_ref(ref, oid, format);

        return 0;
 }

> > Unfortunately, this optimization may not be helpful for git cat-file --batch,
> > see [1], batch_object_write() directly constructs a ref_array_item and call
> > format_ref_array_item() to grab data, It does not use ref_array. So it also
> > does not have this malloc() | free() overhead.
>
> Right. It would only be helped by the "quick" formats in the second
> patch (and by skipping the malloc/free of the individual
> ref_array_items).
>

Yes, your test is indeed worth thinking about: how to avoid
intermediate data to reduce overhead.

> -Peff

Thanks.
--
ZheNing Hu
Previous: Jeff KingNext: Jeff King
Message 5 of 26 in “speeding up trivial for-each-ref invocations”
  1. 0/2 speeding up trivial for-each-ref invocationsJeff King, Sep 4, 2021
  2. 1/2 ref-filter: hacky "streaming" modeJeff King, Sep 4, 2021
  3. ZheNing HuSep 5, 2021
  4. Jeff KingSep 5, 2021
  5. ZheNing HuSep 7, 2021
  6. Jeff KingSep 7, 2021
  7. ZheNing HuSep 9, 2021
  8. Jeff KingSep 10, 2021
  9. ZheNing HuSep 15, 2021
  10. ZheNing HuSep 15, 2021
  11. Jeff KingSep 16, 2021
  12. ZheNing HuSep 20, 2021
  13. Jeff KingSep 16, 2021
  14. Jeff KingSep 5, 2021
  15. ZheNing HuSep 7, 2021
  16. 2/2 ref-filter: implement "quick" formatsJeff King, Sep 4, 2021
  17. ZheNing HuSep 5, 2021
  18. Jeff KingSep 5, 2021
  19. ZheNing HuSep 6, 2021
  20. Junio C HamanoSep 7, 2021
  21. ZheNing HuSep 5, 2021
  22. Jeff KingSep 5, 2021
  23. ZheNing HuSep 6, 2021
  24. Jeff KingSep 7, 2021
  25. ZheNing HuSep 9, 2021
  26. Patrick SteinhardtSep 6, 2021

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.