On Sat, Feb 19, 2022 at 10:14 AM Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > Hi, > > Elijah Newren wrote: > > > And, of course, you're trying to do more than just detect > > inconsistencies -- you want the vfs to fully control the sparsity > > patterns and expand them based on dynamic file accesses by the user. > > That dynamic bit doesn't play well with the non-vfs workaround. > > > > > > Does that sound right? > > You captured some of it. There's a bit more: typically when using > sparse checkout the traditional way, you will not have files in your > working directory that do not match the sparse checkout pattern. That > way, the disk usage in the working copy is nice and small. But with a > vfsd like described in [2], having other files in the working > directory does not cost disk usage because the corresponding data even > in compressed (git object) form does not have to be present locally > until the files are accessed. So a vfsd gives an end user the > illusion that all files are present, whereas git only operates on a > small subset (the working set). > > With this change, git would start operating on all the files. > > [...] > > Side note: I thought Microsoft's vfs was first named GVFS and then > > based on naming collisions renamed to VFS for Git. Sounds like you > > have something that is probably a bit different, but which you are > > also calling VFS for Git? > > No, sorry for the lack of clarity. When I say "VFS for Git", I > genuinely mean https://vfsforgit.org/, which was authored by Microsoft > and to my understanding is still used by Microsoft's Windows team and > is available for anyone to use. (That page currently returns a cert > error because their SSL cert expired 10 days ago. But hopefully it > conveys the idea, and the content is still there if you go through the > interstitial.) > > I agree that it can be kind of confusing to talk about that alongside > VFSes in general, but I didn't choose the name. :) > > [...] > > On Fri, Feb 18, 2022 at 5:07 PM Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > >> a. We could guard it with a config option. It would still be a > >> regression for VFS for Git users, but they'd be able to use the > >> config option to restore the expected behavior. > [...] > >> b. We could distinguish between the vfsd and the "interrupted and > >> forgot to update SKIP_WORKTREE bits in the index" cases somehow. > >> This sounds complex. > >> > >> c. Something else? > >> > >> (b) and (c) aren't sounding obviously good, so (a) seems tempting. > >> What do you think? > > > > Yeah, I'm having a hard time coming up with a way that either the VFS > > could recognize these special Git present-despite-skip-worktree checks > > and treat them differently, or having Git recognize that it is running > > under a special VFS that likes to aggressively and automagically > > expand the sparsity patterns. So (a) seems tempting to me too. > > Thanks. In a way it feels like giving up (isn't it better when things > automagically Just Work?), but I think it's the right thing to do. > > > Got any name suggestions? core.avoidPresentDespiteSkipWorktreeCheck > > (defaulting to false)? core.sparsityConsistencyCheck (defaulting to > > true)? > > > > Did your team want to implement that on top of > > en/present-despite-skipped since you can verify if it works for you, > > or did you want me to take a stab at it? Should be a pretty simple > > change. > > Monday is a holiday here; it shouldn't be hard to get a patch out > later this week. Happy to write one but I also won't be at all offended > if someone else writes it first. > > Ideally the config name should describe the intent from the user's > perspective instead of the implementation. So something like > "sparsecheckout.expectFilesOutsideSparsePattern". > > Thanks, > Jonathan I took a stab at it over here: https://lore.kernel.org/git/pull.1153.git.1645333542011.gitgitgadget@xxxxxxxxx/ Let me know if that works for you.
