Hi Peff, On Wed, 22 Nov 2017, Jeff King wrote: > On Wed, Nov 22, 2017 at 01:56:35PM -0800, Jonathan Nieder wrote: > > > Jeff King wrote: > > > On Wed, Nov 22, 2017 at 12:27:20PM -0800, Jonathan Nieder wrote: > > > > >> That said, I wonder if this use case is an illustration that a name > > >> like --no-lock-index (as was used in Git for Windows when this feature > > >> first appeared) or --no-refresh-on-disk-index (sorry, I am terrible at > > >> coming up with option names) would make the feature easier to > > >> discover. > > [...] > > > Or maybe just living with the minor philosophical rough edges, > > > since it seems OK in practice. > > > > To be clear, my concern is not philosophical but practical: I'm saying > > if it's a "git status" option (or at least shows up in the "git > > status" manpage) and it is memorably about $GIT_DIR/index (at least > > mentions that in its description) then it is more likely to help > > people. > > Right, I went a little off track of your original point. > > What I was trying to get at is that naming it "status --no-lock-index" > would not be the same thing (even though with the current implementation > it would behave the same). IOW, can we improve the documentation of > "status" to point to make it easier to discover this use case. I had the hunch that renaming the option (and moving it away from `git status`, even if it is currently only affecting `git status` and even if it will most likely be desirable to have the option to really only prevent `git status` from writing .lock files) was an unfortunate decision (and made my life as Git for Windows quite a bit harder than really necessary, it cost me over one workday of a bug hunt, mainly due to a false flag indicating `git rebase` to be the culprit). And I hinted at it, too. Maybe I should trust my instincts and act on them more. It is not like it was the first time that I had doubts that turned out to have merit, see e.g. the regression introduced into the formerly rock-solid set_hidden_flag() patches due to changes I made reluctantly during upstreaming, or the regression introduced during v1->v2 in my regex-buf patches that caused problems with mulibc and AIX. I really never understood why --no-optional-locks had to be introduced when it did exactly the same as --no-lock-index, and when the latter has a right to exist in the first place, even in the purely hypothetical case that we teach --no-optional-locks to handle more cases than just `git status`' writing of the index (and in essence, it looks like premature optimization): it is a very concrete use case that a user may want `git status` to refrain from even trying to write any file, as this thread shows very eloquently. Maybe it is time to reintroduce --no-lock-index, and make --no-optional-locks' functionality a true superset of --no-lock-index'. At least that is what my gut feeling tells me should be done. Ciao, Dscho
