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

Re: git status reads too many files

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 21, 2011, 16:41 UTC
Message-ID
<7vipvcs9xt.fsf@alter.siamese.dyndns.org>
In-Reply-To
<AANLkTikV4S51DXLADiRXWqjXdTD1OBLSdKjEWALZ9Ebh@mail.gmail.com>
Lasse Makholm <lasse.makholm@gmail.com> writes:
Show 12 quoted lines
> This persistent across multiple runs of git status:
>
> $ strace -o /tmp/trace2 git status
> # On branch there
> nothing to commit (working directory clean)
> $ grep ^open /tmp/trace2 | wc -l
> 414
> $
>
> ...until the index is touched:
>
> $ touch .git/index
Don't do this; you are breaking the racy-git protection.

I think we opportunistically update the .git/index file in "git status" to refresh the stat bits (but we don't error out when we cannot write a new index, as you may be only browsing somebody else's repository with only a read access to it). It probably should be just the matter of adding a bit of logic to notice that your index is racily clean.

Let me cook something real quick.
Previous: Lasse MakholmNext: Junio C Hamano
Message 2 of 9 in “git status reads too many files”
  1. Lasse MakholmMar 21, 2011
  2. Junio C HamanoMar 21, 2011
  3. 1/2 diff/status: refactor opportunistic index updateJunio C Hamano, Mar 21, 2011
  4. Piotr KrukowieckiMar 21, 2011
  5. Junio C HamanoMar 21, 2011
  6. 2/2 update $GIT_INDEX_FILE when there are racily clean entriesJunio C Hamano, Mar 21, 2011
  7. Lasse MakholmMar 21, 2011
  8. Eric RaibleMar 22, 2011
  9. Lasse MakholmMar 21, 2011

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.