Re: git status always modifies index?

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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