Re: git status always modifies index?

From: Jeff King <peff@peff.net>
Date: Nov 26, 2017, 19:27 UTC
Message-ID: <20171126192749.GC1501@sigill>
In-Reply-To: <xmqqwp2diuki.fsf@gitster.mtv.corp.google.com>

On Sun, Nov 26, 2017 at 12:32:13PM +0900, Junio C Hamano wrote:

Show 13 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > 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.
> 
> Yeah, the name is unfortunate. 
> 
> What the end user really wants to see, I suspect, is a "--read-only"
> option that applies to any filesystem entity and to any command, in
> the context of this thread, and also in the original discussion that
> led to the introduction of that option.

I'm not sure I agree. Lockless writes are actually fine for the original use case of --no-optional-locks (which is a process for the same user that just happens to run in the background). I can buy the distinction between that and "--read-only" as premature optimization, though, since it's not common for most operations to do non-locking writes (pretty much object writes are the only thing, and most "semantically read-only" operations like status or diff do not write any objects).

So there's very little lost by people in the first boat saying "--read-only".

-Peff