From: Junio C Hamano <gitster@pobox.com>
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>, "Patrick Steinhardt" <ps@pks.im>,
"Jean-Noël Avila" <avila.jn@gmail.com>,
"John Cai" <johncai86@gmail.com>
Subject: Re: [PATCH 1/4] refs: add referent parameter to refs_resolve_ref_unsafe
Date: Thu, 06 Jun 2024 11:21:21 -0700 [thread overview]
Message-ID: <xmqq34pqlyou.fsf@gitster.g> (raw)
In-Reply-To: <011c10f488610b0a795a843bff66723477783761.1717694801.git.gitgitgadget@gmail.com>
ADMINISTRIVIA. Check the address you place on the CC: line. What
we can see for this message at
https://lore.kernel.org/git/011c10f488610b0a795a843bff66723477783761.1717694801.git.gitgitgadget@gmail.com/raw
looks like this.
Cc: "Phillip Wood [ ]" <phillip.wood123@gmail.com>,
Kristoffer Haugsbakk <[code@khaugsbakk.name]>,
"Jeff King [ ]" <peff@peff.net>,
"Patrick Steinhardt [ ]" <ps@pks.im>,
"=?UTF-8?Q?Jean-No=C3=ABl?= Avila [ ]" <avila.jn@gmail.com>,
John Cai <johncai86@gmail.com>,
John Cai <johncai86@gmail.com>
I fixed them manually, but it wasn't pleasant. I think we saw a
similar breakage earlier coming via GGG, but I do not recall the
details of how to cause such breakages (iow, what to avoid repeating
this).
Anyway.
"John Cai via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 29 files changed, 64 insertions(+), 52 deletions(-)
Wow, the blast radius of this thing is rather big. Among these
existing callers of refs_resolve_ref_unsafe(), how many of them
will benefit from being able to pass a non NULL parameter at the end
of the series, and more importantly, in the future to take advantage
of the new feature possibly with a separate series?
I am assuming that this will benefit only a selected few and the
callers that would want to take advantage of the new feature will
remain low. Have you considered renaming refs_resolve_ref_unsafe()
to a new name (say, refs_resolve_ref_unsafe_with_referent()) and
implement the new feature (which is only triggered when the new
parameter gets a non NULL value), make refs_resolve_ref_unsafe() a
very thin wrapper that passes NULL to the new thing?
That way, you do not have to touch those existing callers that will
never benefit from the new capability in the future. You won't risk
conflicting with in flight topics semantically, either.
Or will they also benefit from the new feature in the future?
Offhand, I do not know how a caller like this ...
> diff --git a/add-interactive.c b/add-interactive.c
> index b5d6cd689a1..041d30cf2b3 100644
> --- a/add-interactive.c
> +++ b/add-interactive.c
> @@ -533,7 +533,7 @@ static int get_modified_files(struct repository *r,
> {
> struct object_id head_oid;
> int is_initial = !refs_resolve_ref_unsafe(get_main_ref_store(the_repository),
> - "HEAD", RESOLVE_REF_READING,
> + "HEAD", NULL, RESOLVE_REF_READING,
> &head_oid, NULL);
> struct collection_status s = { 0 };
> int i;
... would be helped.
Thanks.
next prev parent reply other threads:[~2024-06-06 18:21 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 17:26 [PATCH 0/4] keep track of unresolved value of symbolic-ref in ref iterators John Cai via GitGitGadget
2024-06-06 17:26 ` [PATCH 1/4] refs: add referent parameter to refs_resolve_ref_unsafe John Cai via GitGitGadget
2024-06-06 18:21 ` Junio C Hamano [this message]
2024-06-06 18:23 ` Junio C Hamano
2024-06-07 13:43 ` John Cai
2024-06-07 15:21 ` Junio C Hamano
2024-06-10 7:29 ` Patrick Steinhardt
2024-06-10 18:09 ` Junio C Hamano
2024-06-06 21:02 ` John Cai
2024-06-06 22:44 ` Junio C Hamano
2024-06-28 15:30 ` Kristoffer Haugsbakk
2024-06-28 19:47 ` Junio C Hamano
2024-06-30 10:12 ` Linus Arver
2024-06-30 18:19 ` Junio C Hamano
2024-06-11 8:50 ` Jeff King
2024-07-30 14:38 ` John Cai
2024-06-06 17:26 ` [PATCH 2/4] refs: keep track of unresolved reference value in iterators John Cai via GitGitGadget
2024-06-11 9:01 ` Jeff King
2024-06-06 17:26 ` [PATCH 3/4] refs: add referent to each_ref_fn John Cai via GitGitGadget
2024-06-06 17:26 ` [PATCH 4/4] ref-filter: populate symref from iterator John Cai via GitGitGadget
2024-08-01 14:58 ` [PATCH v2 0/3] keep track of unresolved value of symbolic-ref in ref iterators John Cai via GitGitGadget
2024-08-01 14:58 ` [PATCH v2 1/3] refs: keep track of unresolved reference value in iterators John Cai via GitGitGadget
2024-08-01 16:41 ` Junio C Hamano
2024-08-05 10:59 ` Patrick Steinhardt
2024-08-05 15:40 ` Junio C Hamano
2024-08-01 14:58 ` [PATCH v2 2/3] refs: add referent to each_ref_fn John Cai via GitGitGadget
2024-08-01 14:58 ` [PATCH v2 3/3] ref-filter: populate symref from iterator John Cai via GitGitGadget
2024-08-01 16:43 ` Junio C Hamano
2024-08-01 16:51 ` Junio C Hamano
2024-08-01 16:54 ` Junio C Hamano
2024-08-06 19:49 ` John Cai
2024-08-06 20:17 ` Junio C Hamano
2024-08-07 19:42 ` [PATCH v3 0/3] keep track of unresolved value of symbolic-ref in ref iterators John Cai via GitGitGadget
2024-08-07 19:42 ` [PATCH v3 1/3] refs: keep track of unresolved reference value in iterators John Cai via GitGitGadget
2024-08-07 21:40 ` Junio C Hamano
2024-08-08 18:09 ` John Cai
2024-08-07 19:42 ` [PATCH v3 2/3] refs: add referent to each_ref_fn John Cai via GitGitGadget
2024-08-07 19:42 ` [PATCH v3 3/3] ref-filter: populate symref from iterator John Cai via GitGitGadget
2024-08-09 15:37 ` [PATCH v4 0/3] keep track of unresolved value of symbolic-ref in ref iterators John Cai via GitGitGadget
2024-08-09 15:37 ` [PATCH v4 1/3] refs: keep track of unresolved reference value in iterators John Cai via GitGitGadget
2024-11-23 8:24 ` shejialuo
2024-08-09 15:37 ` [PATCH v4 2/3] refs: add referent to each_ref_fn John Cai via GitGitGadget
2024-08-09 15:37 ` [PATCH v4 3/3] ref-filter: populate symref from iterator John Cai via GitGitGadget
2024-08-09 16:51 ` [PATCH v4 0/3] keep track of unresolved value of symbolic-ref in ref iterators Junio C Hamano
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=xmqq34pqlyou.fsf@gitster.g \
--to=gitster@pobox.com \
--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 \
--cc=ps@pks.im \
/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 NNTP newsgroup(s).