git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Derrick Stolee <derrickstolee@github.com>
To: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Jonathan Tan <jonathantanmy@google.com>,
	jabolopes@google.com, Jeff Hostetler <jeffhostetler@github.com>,
	Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH] Provide config option to expect files outside sparse patterns
Date: Sun, 20 Feb 2022 14:41:55 -0500	[thread overview]
Message-ID: <54a0aa74-57c2-ee65-ae07-cb1b0daf947f@github.com> (raw)
In-Reply-To: <pull.1153.git.1645333542011.gitgitgadget@gmail.com>

On 2/20/2022 12:05 AM, Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@gmail.com>
> 
> Typically with sparse checkouts, we expect files outside the sparsity
> patterns to be marked as SKIP_WORKTREE and be missing from the working
> tree.  VFS for Git can be used to turn this expectation on its head:
> all files are considered present in the working copy, though they are
> not vivified until first access access.  With VFS for Git, most of the
> files do not match the sparsity patterns at first, and the VFS layer
> automatically updates the sparsity patterns to add more files whenever
> files are written.
> 
> With this background, this special usecase does not play well with the
> safety check we added in commit 11d46a399d ("repo_read_index: clear
> SKIP_WORKTREE bit from files present in worktree", 2022-01-06).
> Checking SKIP_WORKTREE files to see if they are present in the working
> tree causes them all to be immediately vivified.  Further, the special
> VFS layer, by virtue of automatically updating the sparsity patterns and
> catching all accesses, isn't in need of that safety check either.
> Provide a configuration option, core.expectFilesOutsideSparsePatterns
> so that those with this special usecase can turn off the safety check.

This patch looks like a good solution to the concerns brought up by
Jonathan N. around vfsd. VFS for Git uses the microsoft/git fork with
its own custom config to protect things like this. I imagine that we
will start setting your core_expect_files_outside_sparse_patterns
variable when reading the virtual filesystem info. We might even modify
some of our custom checks to use this variable instead. That would make
them appropriate to send upstream.

Should we update Documentation/config/core.txt describing this config
key? Or is this intended to be an internal detail only for something
like vfsd?

The only concern here really is if we want to be picky about the "VFS
for Git" references instead of "vfsd" references in the commit message.

Thanks,
-Stolee

  reply	other threads:[~2022-02-20 19:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-20  5:05 [PATCH] Provide config option to expect files outside sparse patterns Elijah Newren via GitGitGadget
2022-02-20 19:41 ` Derrick Stolee [this message]
2022-02-20 20:16   ` Junio C Hamano
2022-02-22  2:17   ` Elijah Newren
2022-02-22 12:28     ` Johannes Schindelin
2022-02-22 13:43       ` Derrick Stolee
2022-02-21 20:34 ` Johannes Schindelin
2022-02-21 22:53   ` Ævar Arnfjörð Bjarmason
2022-02-22  2:25     ` Elijah Newren
2022-02-22 12:13       ` Johannes Schindelin
2022-02-22 12:57         ` Ævar Arnfjörð Bjarmason
2022-02-22 23:13           ` Jonathan Nieder
2022-02-25 16:39             ` Ævar Arnfjörð Bjarmason
2022-02-22  2:23   ` Elijah Newren
2022-02-22 10:05     ` Ævar Arnfjörð Bjarmason
2022-02-22 12:11     ` Johannes Schindelin
2022-02-22 13:47     ` Derrick Stolee
2022-02-23  2:26 ` [PATCH v2] repo_read_index: add config " Jonathan Nieder
2022-02-23  3:10   ` Elijah Newren
2022-02-24  5:22   ` [PATCH v3] " Elijah Newren
2022-02-24 18:24     ` Junio C Hamano
2022-02-26  5:58       ` Elijah Newren
2022-02-25 16:33     ` Jonathan Nieder
2022-02-26  6:01       ` Elijah Newren
2022-02-26  6:12     ` [PATCH v4] " Elijah Newren
2022-03-02  4:33       ` [PATCH v5] " Elijah Newren
2022-03-02  7:36         ` Junio C Hamano
2022-03-02  8:01           ` Elijah Newren
2022-03-02 13:37       ` [PATCH v4] " Derrick Stolee

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=54a0aa74-57c2-ee65-ae07-cb1b0daf947f@github.com \
    --to=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jabolopes@google.com \
    --cc=jeffhostetler@github.com \
    --cc=jonathantanmy@google.com \
    --cc=jrnieder@gmail.com \
    --cc=newren@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).