Jeff King <peff@xxxxxxxx> writes: > I admit that's just adding more hand-waving to the pile. But I don't > think it really _hurts_ to leave that door open (aside from making the > documentation a bit wishy-washy). And it helps because callers would > pick up the new features automatically, without having to learn about a > new option. Oh, I do agree it is a good idea to leave that door open, so that scripts that rely on today's --no-optional-locks option will not have to be updated when a similar feature (like the "ref compaction" example you mentioned) against which "let's disable when we are not the primary process, in order to keep the interference to the minimum" would be something we would want to say. The option being added here should cover these future needs. > And I think that's really what this option is. It is less about the > caller asking for some specific behavior, and more about them telling > Git about the context in which it's executing so it can make intelligent > decisions. Yes, indeed.
