Hi,
Jeff King wrote:
> On Sun, Nov 26, 2017 at 06:35:56PM +0900, Junio C Hamano wrote:
>> 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
