Re: git status always modifies index?

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Nov 27, 2017, 20:57 UTC
Message-ID: <20171127205731.GB27469@aiede.mtv.corp.google.com>
In-Reply-To: <20171127044314.GA6236@sigill>

Hi,

Jeff King wrote:

> On Sun, Nov 26, 2017 at 06:35:56PM +0900, Junio C Hamano wrote:

Show 14 quoted lines

>> Having a large picture option like "--read-only" instead of ending
>> up with dozens of "we implemented a knob to tweak only this little
>> piece, and here is an option to trigger it" would help users in the
>> long run, but we traditionally did not do so because we tend to
>> avoid shipping "incomplete" features, but being perfectionist with
>> such a large undertaking can stall topics with feature bloat.  In a
>> case like this, however, I suspect that an aspirational feature that
>> starts small, promises little and can be extended over time may be a
>> good way to move forward.
>
> I actually consider "--no-optional-locks" to be such an aspirational
> feature. I didn't go digging for other cases (though I'm fairly certain
> that "diff" has one), but hoped to leave it for further bug reports ("I
> used the option, ran command X, and saw lock contention").

I am worried that the project is not learning from what happened here.

My main issue with the --no-optional-locks name is that it does not connect to the underlying user need. Your main argument for it is that it exactly describes the underlying user need. One of us has to be wrong.

So let me describe my naive reading:

As a user, I want to inspect the state of the repository without disrupting it in any way. That means not breaking concurrent processes and not upsetting permissions. --read-only seems to describe this use case to me perfectly.

If I understood correctly, your objection is that --read-only is not specific enough. What I really want, you might say, is not to break concurrent processes. Any other aspects of being read-only are not relevant. E.g. if I can refresh the on-disk index using O_APPEND without disrupting concurrent processes then I should be satisfied with that.

Fair enough, though that feels like overengineering. But I *still* don't see what that has to do with the name "no-optional-locks". When is a lock *optional*? And how am I supposed to discover this option?

This also came up during review, and I am worried that this review feedback is being ignored. In other words, I have no reason to believe it won't happen again.

> I would be fine with having a further aspirational "read only" mode.

Excellent, we seem to agree on this much. If I can find time for it today then I'll write a patch.

Thanks, Jonathan