Re: git status always modifies index?

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 25, 2017, 21:55 UTC
Message-ID: <alpine.DEB.2.21.1.1711252240300.6482@virtualbox>
In-Reply-To: <20171122220627.GE2854@sigill>

Hi Peff,

On Wed, 22 Nov 2017, Jeff King wrote:

Show 26 quoted lines

> 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