Re: git status always modifies index?

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 26, 2017, 09:35 UTC
Message-ID: <xmqq7eudidqb.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqwp2diuki.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 18 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.  
>
> While I think the variable losing "index" from its name was a vast
> improvement relative to "--no-lock-index", simply because it
> expresses what we do a bit closer to "do not just do things without
> modifying anything my repository", it did not go far enough.

Yuck, the last sentence was garbled. What I meant as the ideal "read-only" was "do things without modifying anything in my repository".

And to avoid any misunderstanding, what I mean by "it did not go far enough" is *NOT* this:

    We added a narrow feature and gave it a narrow name.  Instead we
    should have added a "--read-only" feature, which this change may
    be a small part of, and waited releasing the whole thing until
    it is reasonably complete.

By going far enough, I was wondering if we should have done something that we historically did not do. An "aspirational" feature that is incrementally released with a known bug and that will give users what they want in the larger picture when completed.

IOW, we could have made this "git --read-only <cmd>", that is explained initially as "tell Git not to modify repository when it does not have to (e.g. avoid opportunistic update)" and perhaps later as "tell Git not to modify anything in the repository--if it absolutely has to (e.g. "git --read-only commit" is impossible to complete without modifying anything in the repository), error out instead". And with a known-bug section to clearly state that this feature is not something we vetted every codepath to ensure the read-only operation, but is still a work in progress.

After all, "status" does not have to stay to be the only command with opportunistic modification (in the current implementation, it does "update-index --refresh" to update the index). And the index does not have to stay to be the only thing that is opportunistically modified (e.g. "git diff --cached" could not just opportunistically update the index, but also it could be taught to write out tree objects for intermediate directories when it does its cache-tree refresh, which would help the diff-index algorithm quite a bit in the performance department).

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.