git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] [RFC][GSoC][PATCH] attr: use local repository state in read_attr

From
Tian Yuchen <a3205153416@gmail.com>
Date
Feb 11, 2026, 16:43 UTC
Message-ID
<83365a16-68c2-4429-926e-3071df3b9bfb@gmail.com>
In-Reply-To
<xmqqqzqsw4og.fsf@gitster.g>
On 2/11/26 07:37, Junio C Hamano wrote:
Show 26 quoted lines
> Tian Yuchen<a3205153416@gmail.com> writes:
> 
>> Junio C Hamano<gitster@pobox.com> writes:
>>
>>   >The codepath read_attr() is in is usually not that hot but it is not
>>   >cheap.
>>
>> I'm a bit curious—under what circumstances would calling this method
>> result in significant performance regression?
> Significant?  I dunno.
> 
> And quite honestly, I do not care about significance very much in a
> case like this.  Doing things that do not make sense, like checking
> the same configuration variable again and again when you_know_ that
> you never switched to a different repository since you last checked,
> is simply wrong.  It burdens the readers with unnecessary cognitive
> load by making them wonder why you do such a nonsensical thing.
> 
> The read_attr() is called during an attr stack construction, which
> traverses the directory hierarchy of a single repositry's working
> tree (we do not traverse across submodule boundaries), and the same
> istate (i.e., index contents) structure is passed around throughout
> the callchain.  The repository instance at istate->repo may be a
> good place to store "am I bare?" bit that is computed just once and
> reused whenever we need to know, like in the funcion under
> discussion.
Hi Junio,

I completely agree that computing it once and storing it in 'istate->repo' is the right fix. Optimizing for logical clarity and reducing load is indeed more important than micro-benchmarking here.

Thanks for the insight!
Regards,
Yuchen
Previous: Junio C Hamano
Message 10 of 10 in “attr: use local repository state in read_attr”
  1. [RFC][GSoC][PATCH] attr: use local repository state in read_attrAyush Jha, Feb 7, 2026
  2. Tian YuchenFeb 7, 2026
  3. Lucas Seiki OshiroFeb 7, 2026
  4. Junio C HamanoFeb 7, 2026
  5. Tian YuchenFeb 8, 2026
  6. Ayush JhaFeb 10, 2026
  7. Lucas Seiki OshiroFeb 14, 2026
  8. Ayush JhaFeb 14, 2026
  9. Junio C HamanoFeb 10, 2026
  10. Tian YuchenFeb 11, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.