From: Patrick Steinhardt <ps@pks.im>
To: Xinyu Ruan via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Xinyu Ruan <r200981113@gmail.com>
Subject: Re: [PATCH] refs: don't clear oid before read_raw_ref in the debug ref backend
Date: Fri, 31 Oct 2025 07:48:42 +0100 [thread overview]
Message-ID: <aQRbygXjkffQoNPi@pks.im> (raw)
In-Reply-To: <pull.2089.git.git.1761881825025.gitgitgadget@gmail.com>
On Fri, Oct 31, 2025 at 03:37:05AM +0000, Xinyu Ruan via GitGitGadget wrote:
> From: Xinyu Ruan <r200981113@gmail.com>
>
> The debug_read_raw_ref function clears the oid to null_oid before
> calling read_raw_ref, which causes the oid to be lost even when
> read_raw_ref successfully reads the reference.
This sentence doesn't quite make sense to me. If `read_raw_ref()`
succeeds, wouldn't we expect that the OID was set to the target's object
ID anyway? So why does it hurt to set the object ID to the null ID if
it's going to get rewritten anyway?
Another question is why we were setting it to the null OID in the first
place. Ideally, this should be discussed in the commit message.
> This leads to failures
> when executing commands like "git branch new_branch <commit_id>" with
> GIT_TRACE_REFS=1, as the command cannot find a valid branch point
> because the oid is null.
This smells like an issue that can be be demonstrated via a unit test.
Right now though we got zero testing for `GIT_TRACE_REFS` in our test
suite. Maybe this could be used as a starting point for a new test suite
"t0620-ref-debug.sh" that exercises the different callbacks?
Thanks!
Patrick
prev parent reply other threads:[~2025-10-31 6:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-31 3:37 [PATCH] refs: don't clear oid before read_raw_ref in the debug ref backend Xinyu Ruan via GitGitGadget
2025-10-31 6:48 ` Patrick Steinhardt [this message]
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=aQRbygXjkffQoNPi@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=r200981113@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 NNTP newsgroup(s).