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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> Johannes, this is an adaptation of your 67e5ce7f63 (status: offer *not*
> to lock the index and update it, 2016-08-12). Folks working on GitHub
> Desktop complained to me that it's only available on Windows. :)
>
> I expanded the scope a bit to let us give the same treatment to more
> commands in the long run.  I'd also be OK with just cherry-picking your
> patch to non-Windows Git if you don't find my reasoning below
> compelling. But I think we need _something_ like this, as the other
> solutions I could come up with don't seem very promising.

The phrase 'optional lock' does not answer this question clearly,
though: does it make sense to extend the coverage of this option in
the future to things more than the "opportunistic update to the
index file"?

If the answer is no, then having 'index' instead of 'lock' in the
name of the option would make more sense (and 'opportunistic' over
'optional', too), because what the change is about is to allow other
processes that are directly interacting with the user to update the
index, and 'lock' being hindrance is merely an implementation
detail.  The comment on the "test" in the log message mentions as if
it were a short-coming that it does not check the lock but checks
if the index is written, but I think that is testing what matters
and preferable than testing "did we lock and then unlock it?"

On the other hand, if the answer is yes, then I am curious what
other things this may extend to, and if these other things are also
opportunistic optimizations.

Other than that, I think this change (including the part that this
is done globally and down to subprocesses as needed) makes sense.

Thanks (and sorry for not being Johannes ;-).