Re: git status always modifies index?

From: Jeff King <peff@peff.net>
Date: Nov 26, 2017, 19:25 UTC
Message-ID: <20171126192508.GB1501@sigill>
In-Reply-To: <alpine.DEB.2.21.1.1711252240300.6482@virtualbox>

On Sat, Nov 25, 2017 at 10:55:25PM +0100, Johannes Schindelin wrote:

Show 14 quoted lines

> > 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.

I remain unconvinced that we have actually uncovered a serious problem. Somebody asked if Git could do a thing, and people pointed him to the right option. That option is new in the latest release. So it is entirely plausible to me that the new option is just fine and:

  1. We could adjust the documentation to cross-reference from
     git-status.

  2. Now that the new option exists, informal documentation will start
     to mention it. Including this thread in the mailing list archive,
     and the stack overflow thread that was linked.

Show 8 quoted lines

> 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.

Besides potentially handling more than just "git status", it differs in one other way: it can be triggered via and is carried through the environment.

> Maybe it is time to reintroduce --no-lock-index, and make
> --no-optional-locks' functionality a true superset of --no-lock-index'.

I'm not against having a separate option for "never write to the repository". I think it's potentially different than "don't lock", as I mentioned earlier. Frankly I don't see much value in "--no-lock-index" if we already have "--no-optional-locks". But I figured you would carry "status --no-lock-index" forever in Git for Windows anyway (after all, if you remove it now, you're breaking compatibility for existing users).

-Peff