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

Re: [PATCH v2 1/3] refs: keep track of unresolved reference value in iterator

From
Patrick Steinhardt <ps@pks.im>
Date
Apr 11, 2024, 09:11 UTC
Message-ID
<ZhepXm4G1OJqo6jq@tanuki>
In-Reply-To
<xmqqwmp5xmqy.fsf@gitster.g>
On Wed, Apr 10, 2024 at 08:26:13AM -0700, Junio C Hamano wrote:
Show 26 quoted lines
> Patrick Steinhardt <ps@pks.im> writes:
> 
> >>  const char *refs_resolve_ref_unsafe(struct ref_store *refs,
> >>  				    const char *refname,
> >> +				    char **referent,
> >>  				    int resolve_flags,
> >>  				    struct object_id *oid,
> >>  				    int *flags)
> >
> > I wonder whether this really should be a `char **`. You don't seem to be
> > free'ing returned pointers anywhere, so this should probably at least be
> > `const char **` to indicate that memory is owned by the ref store. But
> > that would require the ref store to inevitably release it, which may
> > easily lead to bugs when the caller expects a different lifetime.
> >
> > So how about we instead make this a `struct strbuf *referent`? This
> > makes it quite clear who owns the memory. Furthermore, if the caller
> > wants to resolve multiple refs, it would allow them to reuse the buffer
> > for better-optimized allocation patterns.
> 
> Or return an allocated piece of memory via "char **".  I think an
> interface that _requires_ the caller to use strbuf is not nice, if
> the caller is not expected to further _edit_ the returned contents
> using the strbuf API.  If it is likely that the caller would want to
> perform further post-processing on the result, an interface based on
> strbuf is nice, but I do not think it applies to this case.

When iterating through refs this would incur one allocation per ref though, whereas using a `struct strbuf` would only require a single one.

Patrick
Previous: Junio C HamanoNext: John Cai via GitGitGadget
Message 21 of 28 in “show-ref: add --unresolved option”
  1. show-ref: add --unresolved optionJohn Cai via GitGitGadget, Mar 4, 2024
  2. Junio C HamanoMar 4, 2024
  3. John CaiMar 5, 2024
  4. Junio C HamanoMar 5, 2024
  5. Phillip WoodMar 5, 2024
  6. Kristoffer HaugsbakkMar 5, 2024
  7. Jeff KingMar 6, 2024
  8. Junio C HamanoMar 6, 2024
  9. Jeff KingMar 6, 2024
  10. Patrick SteinhardtMar 6, 2024
  11. Jeff KingMar 6, 2024
  12. Junio C HamanoMar 6, 2024
  13. Jean-Noël AvilaMar 6, 2024
  14. 0/3 show-ref: add --symbolic-name optionJohn Cai via GitGitGadget, Apr 8, 2024
  15. 2/3 refs: add referent to each_repo_ref_fnJohn Cai via GitGitGadget, Apr 8, 2024
  16. 1/3 refs: keep track of unresolved reference value in iteratorJohn Cai via GitGitGadget, Apr 8, 2024
  17. Junio C HamanoApr 8, 2024
  18. John CaiApr 9, 2024
  19. Patrick SteinhardtApr 10, 2024
  20. Junio C HamanoApr 10, 2024
  21. Patrick SteinhardtApr 11, 2024
  22. 3/3 show-ref: add --symbolic-name optionJohn Cai via GitGitGadget, Apr 8, 2024
  23. Phillip WoodApr 9, 2024
  24. John CaiApr 11, 2024
  25. phillip.wood123@gmail.comApr 12, 2024
  26. Patrick SteinhardtApr 10, 2024
  27. Junio C HamanoApr 10, 2024
  28. John CaiApr 12, 2024

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.