git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Benjamin Woodruff" <github@benjam.info>
Cc: "Jeff King" <peff@peff.net>,
	 "Benjamin Woodruff via GitGitGadget" <gitgitgadget@gmail.com>,
	 git@vger.kernel.org
Subject: Re: [PATCH 0/2] describe and diff: implement --no-optional-locks
Date: Mon, 10 Mar 2025 16:04:40 -0700	[thread overview]
Message-ID: <xmqq34fk5vxz.fsf@gitster.g> (raw)
In-Reply-To: <bbc8a0ef-737c-44ba-9786-f5456f5ce71b@app.fastmail.com> (Benjamin Woodruff's message of "Mon, 10 Mar 2025 13:50:36 -0700")

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

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

  reply	other threads:[~2025-03-10 23:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-06  5:58 [PATCH 0/2] describe and diff: implement --no-optional-locks Benjamin Woodruff via GitGitGadget
2025-03-06  5:58 ` [PATCH 1/2] describe: " Benjamin Woodruff via GitGitGadget
2025-03-06  5:58 ` [PATCH 2/2] diff: " Benjamin Woodruff via GitGitGadget
2025-03-06 16:11 ` [PATCH 0/2] describe and " Junio C Hamano
2025-03-09  3:39   ` Jeff King
2025-03-10 12:25     ` Junio C Hamano
2025-03-10 16:08       ` Jeff King
2025-03-10 18:53         ` Junio C Hamano
2025-03-10 20:50           ` Benjamin Woodruff
2025-03-10 23:04             ` Junio C Hamano [this message]
2025-03-11  2:10             ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq34fk5vxz.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=github@benjam.info \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).