On Sun, Nov 26, 2017 at 12:32:13PM +0900, Junio C Hamano wrote: > Jeff King <[email protected]> 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
