Re: [PATCH] Provide config option to expect files outside sparse patterns

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 22, 2022, 12:28 UTC
Message-ID: <nycvar.QRO.7.76.6.2202221313400.11118@tvgsbejvaqbjf.bet>
In-Reply-To: <CABPp-BGz0Y+Gk0uLy7K-pqBY955=rN-E2SJFofDaje60b-XZuw@mail.gmail.com>

Hi Elijah,

On Mon, 21 Feb 2022, Elijah Newren wrote:

Show 10 quoted lines

> On Sun, Feb 20, 2022 at 11:41 AM Derrick Stolee
> <derrickstolee@github.com> wrote:
>
> > 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.
>
> I'm not sure I'm understanding the distinction.  Was "VFS for Git"
> renamed to "vfsd"?  Is "vfsd" Google's modified version?  Something
> else?

VFS for Git is the existing project at https://github.com/microsoft/VFSforGit which is pretty much in maintenance mode.

vfsd was mentioned by Jonathan Tan in https://lore.kernel.org/git/20220207190320.2960362-1-jonathantanmy@google.com/. From what I gather, it is a completely separate implementation of the same ideas of VFS for Git, but from what I see it does not share any code with it (and it is unclear how much vfsd tries/tried to learn from VFS for Git, it looks like it's being done from scratch but that impression could be incorrect).

Show 8 quoted lines

> Also, vfsd doesn't seem to be Google-able whereas "VFS for Git" is, and
> since it's not an internal git project, it might be nice to use a name
> that users can find.
>
> But anyway, I have no idea what the "correct" text here is (as
> probably evidenced by my questions), so if anyone wants to provide
> suggestions or corrections to the commit message, I'm happy to take
> them.

How about this?

	Typically with sparse checkouts, we expect files outside the
	sparsity patterns to be marked as SKIP_WORKTREE and be missing
	from the working tree.

	There is currently an effort code-named `vfsd` (see
	https://lore.kernel.org/git/20220207190320.2960362-1-jonathantanmy@google.com/
	for details) to implement a Git-aware virtual file system layer
	(similar in spirit to the VFS for Git project) that 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
	actually accessed.

	With such a virtual file system (VFS) layer, 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.

	Side note: VFS for Git itself requires the Microsoft fork of Git
	to work, therefore this patch would only be needed in that fork,
	as far as VFS for Git is concerned.

Ciao, Dscho