Subject: Re: [PATCH] git: add --no-optional-locks option

From: Junio C Hamano <[email-masked]>
Date: Thu, 21 Sep 2017 14:29:30 +0900

Jeff King <[email-masked]> 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.