On Mon, Mar 10, 2025 at 05:25:32AM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > .... What > > git-status does with --no-optional-locks is to update the index > > internally for its _own_ use (giving it the correct results), but not to > > lock nor write out the resulting index (to avoid conflicting with other > > running programs). So it's pessimal (losing the opportunity to share > > what it learned) but prevents lock contention. > > Yup, that sounds somewhat sensible. I also have to wonder, other > than commands that are clearly about changing the repository state > like "add", the inspection commands like diff and status should > always opportunistically write the index back, without even being > asked? Yeah, certainly it is a potential source of confusion to have a conceptually read-only operation take locks or modify the repo state. But I'm not sure we have a sense of how valuable that optimization is in practice. After touching some files, every git-status, git-diff, etc would end up re-hashing those files instead of using the stat cache. But maybe that is lost in the noise of reading the files to actually do diffs, etc? I dunno. I expect it is more important for status, which probably does not need to read the whole file contents in most cases (and which may be run a lot from the user's prompt, etc). It seems like a big and possibly risky departure from what we've done for so many years. I'm inclined not to rock the boat too much. ;) -Peff
