From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <stolee@gmail.com>
Cc: Jayesh Daga via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Justin Tobler <jltobler@gmail.com>,
Ayush Chandekar <ayu.chandekar@gmail.com>,
Siddharth Asthana <siddharthasthana31@gmail.com>,
Jayesh Daga <jayeshdaga99@gmail.com>
Subject: Re: [PATCH] read-cache: use index state repository for trace2 logging
Date: Fri, 27 Mar 2026 09:28:16 -0700 [thread overview]
Message-ID: <xmqqqzp5kzj3.fsf@gitster.g> (raw)
In-Reply-To: <770465fe-c38f-45a9-b1b0-0ad682a35fab@gmail.com> (Derrick Stolee's message of "Fri, 27 Mar 2026 09:48:55 -0400")
Derrick Stolee <stolee@gmail.com> writes:
> On 3/27/2026 6:08 AM, Jayesh Daga via GitGitGadget wrote:
>
>> Robustness: The ternary fallback ensures we avoid potential NULL pointer
>> dereferences while maintaining existing logging behavior in edge cases.
>
>> + r = istate->repo ? istate->repo : the_repository;
>
> If I understand correctly, it is a bug if istate->repo is NULL.
Because INDEX_STATE_INIT(r) assigns the repository as the first
thing, I tend to agree. A (bare) repository can lack the index
so repo->index might be NULL, but if you have an istate instance,
it should always know which repository it came from.
>> + trace2_data_intmax("index", r, "read/version",
>> istate->version);
>> - trace2_data_intmax("index", the_repository, "read/cache_nr",
>> + trace2_data_intmax("index", r, "read/cache_nr",
>> istate->cache_nr);
>
> Other than that, this is a minor improvement in the right direction. I'd
> rather that it be more complete if you are working in this file.
;-) Long timers always aim higher than posted patches.
> If you are already working in this space, then I recommend figuring out
> how much we can rely on istate->repo and then apply that knowledge to
> these cases as separate commits:
>
> 1. Replace the uses in the trace2 calls with istate->repo
> and delete the TODO comments.
>
> 2. Replace the other uses of the_repository when an istate
> exists already.
Excellent suggestion.
Thanks.
By the way, Jeyesh, do you really want to be known with a numbered
"jayesh0104" as your name? These author identities are cast in
stone in commit objects and will stay with the project.
Also see Documentation/SubmittingPatches::[dco,real-name].
next prev parent reply other threads:[~2026-03-27 16:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-27 10:08 [PATCH] read-cache: use index state repository for trace2 logging Jayesh Daga via GitGitGadget
2026-03-27 13:48 ` Derrick Stolee
2026-03-27 16:28 ` Junio C Hamano [this message]
2026-03-28 5:25 ` jayesh0104
2026-03-28 7:14 ` [PATCH v2] read-cache: use istate->repo " Jayesh Daga via GitGitGadget
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=xmqqqzp5kzj3.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ayu.chandekar@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=jayeshdaga99@gmail.com \
--cc=jltobler@gmail.com \
--cc=siddharthasthana31@gmail.com \
--cc=stolee@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