Re: [PATCH 0/2] describe and diff: implement --no-optional-locks

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 10, 2025, 23:04 UTC
Message-ID: <xmqq34fk5vxz.fsf@gitster.g>
In-Reply-To: <bbc8a0ef-737c-44ba-9786-f5456f5ce71b@app.fastmail.com>

"Benjamin Woodruff" <github@benjam.info> writes:

Show 7 quoted lines

>>> The commands at the Porcelain level, like "status" and "diff",
>>> refresh the index for the CORRECTNESS purposes.
>>
>> Right, but "status" supports --no-optional-locks already.
>
> Does this mean the documentation in `git-status` is incorrect? It
> implies that the background refresh is only for performance reasons.

It has to do, and it does, refresh the in-core index for correctness reasons. Writing the result out to the on-disk file for _other_ processes that will use the index later is a performance hack, and may or may not happen (it is up to what repo_update_index_if_able() does).

If we do not care about redundant refreshing these other processes need to do before they start, we do not have to write the resulting in-core index out to the disk.

Writing the in-core index out for other processes has one downside, which is that for correctness it has to be done under lock. We cannot say "we tried to be nice to others by writing the index file out, but we just found out that there is a competing process trying to open/write the index so let's skip writing it and let them do their thing---they are responsible for refreshing the index for their own use". There needs some coordination, i.e. when we start writing the result of our refreshing the index for others, if other processes need to pay attention to that fact and wait for a while before reading the index, then they benefit because they do not have to refresh the index themselves. Even though our programs, by calling hold_lock_file_for_update(), know how to wait for a bit when this happens, not everybody cooperates.