From: Patrick Steinhardt <ps@pks.im>
To: John Cai via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, "Phillip Wood" <phillip.wood123@gmail.com>,
"Kristoffer Haugsbakk" <code@khaugsbakk.name>,
"Jeff King" <peff@peff.net>,
"Jean-Noël Avila" <avila.jn@gmail.com>,
"John Cai" <johncai86@gmail.com>
Subject: Re: [PATCH v2 1/3] refs: keep track of unresolved reference value in iterator
Date: Wed, 10 Apr 2024 08:52:57 +0200 [thread overview]
Message-ID: <ZhY3SUdrX2WifyZf@tanuki> (raw)
In-Reply-To: <6adc9dd26da4459d246591ce148c960b33bde336.1712597893.git.gitgitgadget@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]
On Mon, Apr 08, 2024 at 05:38:11PM +0000, John Cai via GitGitGadget wrote:
> From: John Cai <johncai86@gmail.com>
[snip]
> @@ -1928,6 +1928,7 @@ int refs_read_symbolic_ref(struct ref_store *ref_store, const char *refname,
>
> 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.
[snip]
> diff --git a/refs/ref-cache.c b/refs/ref-cache.c
> index 9f9797209a4..4c23b92414a 100644
> --- a/refs/ref-cache.c
> +++ b/refs/ref-cache.c
> @@ -34,12 +34,14 @@ struct ref_dir *get_ref_dir(struct ref_entry *entry)
> }
>
> struct ref_entry *create_ref_entry(const char *refname,
> + const char *referent,
> const struct object_id *oid, int flag)
> {
> struct ref_entry *ref;
>
> FLEX_ALLOC_STR(ref, name, refname);
> oidcpy(&ref->u.value.oid, oid);
> + ref->u.value.referent = referent;
> ref->flag = flag;
> return ref;
> }
It's kind of hard to spot the actual changes inbetween all those changes
to callsites. Is it possible to split the patch up such that we have one
patch that changes all the callsites and one patch that does the actual
changes to implement this?
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-04-10 6:53 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-04 22:51 [PATCH] show-ref: add --unresolved option John Cai via GitGitGadget
2024-03-04 23:23 ` Junio C Hamano
2024-03-05 20:56 ` John Cai
2024-03-05 21:29 ` Junio C Hamano
2024-03-05 15:30 ` Phillip Wood
2024-03-05 17:01 ` Kristoffer Haugsbakk
2024-03-06 0:33 ` Jeff King
2024-03-06 2:19 ` Junio C Hamano
2024-03-06 0:41 ` Jeff King
2024-03-06 7:31 ` Patrick Steinhardt
2024-03-06 7:51 ` Jeff King
2024-03-06 16:48 ` Junio C Hamano
2024-03-06 9:36 ` Jean-Noël Avila
2024-04-08 17:38 ` [PATCH v2 0/3] show-ref: add --symbolic-name option John Cai via GitGitGadget
2024-04-08 17:38 ` [PATCH v2 1/3] refs: keep track of unresolved reference value in iterator John Cai via GitGitGadget
2024-04-08 23:02 ` Junio C Hamano
2024-04-09 20:29 ` John Cai
2024-04-10 6:52 ` Patrick Steinhardt [this message]
2024-04-10 15:26 ` Junio C Hamano
2024-04-11 9:11 ` Patrick Steinhardt
2024-04-08 17:38 ` [PATCH v2 2/3] refs: add referent to each_repo_ref_fn John Cai via GitGitGadget
2024-04-08 17:38 ` [PATCH v2 3/3] show-ref: add --symbolic-name option John Cai via GitGitGadget
2024-04-09 15:25 ` Phillip Wood
2024-04-11 19:57 ` John Cai
2024-04-12 9:37 ` phillip.wood123
2024-04-10 6:53 ` Patrick Steinhardt
2024-04-10 15:27 ` Junio C Hamano
2024-04-12 15:23 ` John Cai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZhY3SUdrX2WifyZf@tanuki \
--to=ps@pks.im \
--cc=avila.jn@gmail.com \
--cc=code@khaugsbakk.name \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=johncai86@gmail.com \
--cc=peff@peff.net \
--cc=phillip.wood123@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).