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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 21, 2017, 04:55 UTC
Message-ID: <xmqqbmm4lkf5.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170921043214.pyhdsrpy4omy54rm@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 9 quoted lines

> 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 ;-).