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

Re: Get rid of refreshing cache after "git commit"?

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 17, 2010, 08:27 UTC
Message-ID
<7vljfx87bj.fsf@alter.siamese.dyndns.org>
In-Reply-To
<fcaeb9bf1001170016q5e285201r36f6030579cfa605@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> Nowadays almost (all?) porcelain commands silently refresh index
> before doing anything relating to worktree, I wonder if this tradition
> is still necessary.

Inside "commit", various checks to see if/how worktree files are changed are attempted by the libified diff-files/diff-index and they must be used after you refresh the cache entries.

"git commit" (without paths) does not necessarily have to when you can prove that the user never looks at .git/COMMIT_EDITMSG (e.g. "-F file" is given without "-e"), but otherwise you need to refresh the index to show the correct status in the message buffer.

"git commit paths..." must refresh the named paths (not necessarily the whole index), but again you would need the whole index to show the status correctly.

Previous: Nguyen Thai Ngoc Duy
Message 2 of 2 in “Get rid of refreshing cache after "git commit"?”
  1. Nguyen Thai Ngoc DuyJan 17, 2010
  2. Junio C HamanoJan 17, 2010

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.