From: Junio C Hamano <gitster@pobox.com>
To: "Nathan Froyd via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Nathan Froyd <froydnj@gmail.com>
Subject: Re: [PATCH] builtin/fetch-pack: indicate when we have an exact oid
Date: Thu, 24 Sep 2026 18:51:56 -0700 [thread overview]
Message-ID: <xmqqtsnexflv.fsf@gitster.g> (raw)
In-Reply-To: <pull.2420.git.git.1790257834680.gitgitgadget@gmail.com> (Nathan Froyd via GitGitGadget's message of "Thu, 24 Sep 2026 13:50:34 +0000")
"Nathan Froyd via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Nathan Froyd <froydnj@gmail.com>
>
> The `git fetch` path, when parsing OIDs, properly sets `exact_oid` on
> the relevant refs; the equivalent path for `git fetch-pack` does not.
> This oversight results in an invocation of `git fetch-pack $OID`
> sending `want-ref $OID`, which results in errors like:
>
> fatal: unknown ref $OID
> fatal: remote error: unknown ref $OID
>
> Make the two paths equivalent by setting `exact_oid` properly.
>
> Signed-off-by: Nathan Froyd <froydnj@gmail.com>
> ---
> builtin/fetch-pack: indicate when we have an exact oid
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2420%2Ffroydnj%2Ffroydnj-fetch-pack-exact-oid-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2420/froydnj/froydnj-fetch-pack-exact-oid-v1
> Pull-Request: https://github.com/git/git/pull/2420
>
> builtin/fetch-pack.c | 4 +-
> t/t5703-upload-pack-ref-in-want.sh | 68 ++++++++++++++++++++++++++++++
> 2 files changed, 71 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
> index 86754296fa..bef8a3dfc5 100644
> --- a/builtin/fetch-pack.c
> +++ b/builtin/fetch-pack.c
> @@ -23,13 +23,14 @@ static void add_sought_entry(struct ref ***sought, int *nr, int *alloc,
> struct ref *ref;
> struct object_id oid;
> const char *p;
> + int exact_oid = 0;
>
> if (!parse_oid_hex(name, &oid, &p)) {
> if (*p == ' ') {
> /* <oid> <ref>, find refname */
> name = p + 1;
> } else if (*p == '\0') {
> - ; /* <oid>, leave oid as name */
> + exact_oid = 1; /* <oid>, leave oid as name */
> } else {
> /* <ref>, clear cruft from oid */
> oidclr(&oid, the_repository->hash_algo);
Unlike "git fetch" that is a higher level wrapper, in "git fetch-pack",
a heuristic dwim like this is unwelcome. In
$ git fetch-pack <repository> <ref>...
these <ref> arguments are meant to be passed exactly as given.
I am not sure if there days there still is a reason to run
"fetch-pack" directly instead of "git fetch", as the manual of "git
fetch-pack" itself suggets. But if there is, then shouldn't we give
it an explicit way to say "this is not a ref but is an object name"
in a more unambiguous way. Otherwise, we lose the ability to send
"want-ref 3ce1e94f7d5607971b5de6762bbdb57e86fc5707", even if we
wanted to, which is something "git fetch" does not let you do, and
in turn may be a valid reason why somebody want to use "fetch-pack"
over "fetch" in the first place.
next prev parent reply other threads:[~2026-09-25 1:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 13:50 [PATCH] builtin/fetch-pack: indicate when we have an exact oid Nathan Froyd via GitGitGadget
2026-09-25 1:51 ` Junio C Hamano [this message]
2026-09-25 4:40 ` 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=xmqqtsnexflv.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=froydnj@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@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