From: Elijah Newren <newren@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
Git Mailing List <git@vger.kernel.org>,
Victoria Dye <vdye@github.com>, Derrick Stolee <stolee@gmail.com>,
Lessley Dennington <lessleydennington@gmail.com>,
Jonathan Tan <jonathantanmy@google.com>,
Jose Lopes <jabolopes@google.com>,
Jeff Hostetler <jeffhostetler@github.com>
Subject: Re: [PATCH v2 3/5] repo_read_index: clear SKIP_WORKTREE bit from files present in worktree
Date: Sat, 19 Feb 2022 21:28:59 -0800 [thread overview]
Message-ID: <CABPp-BFEt1zxR6xoZmwmY2dtXkK+ti+g-1DHZCgeP2VpzWqqyA@mail.gmail.com> (raw)
In-Reply-To: <YhEzmdhxHC3W8ijE@google.com>
On Sat, Feb 19, 2022 at 10:14 AM Jonathan Nieder <jrnieder@gmail.com> 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@gmail.com> 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@gmail.com/
Let me know if that works for you.
next prev parent reply other threads:[~2022-02-20 5:29 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-13 16:43 [PATCH 0/5] Remove the present-despite-SKIP_WORKTREE class of bugs (for sparse-checkouts) Elijah Newren via GitGitGadget
2022-01-13 16:43 ` [PATCH 1/5] t1011: add testcase demonstrating accidental loss of user modifications Elijah Newren via GitGitGadget
2022-01-13 16:43 ` [PATCH 2/5] unpack-trees: fix accidental loss of user changes Elijah Newren via GitGitGadget
2022-01-13 16:43 ` [PATCH 3/5] repo_read_index: clear SKIP_WORKTREE bit from files present in worktree Elijah Newren via GitGitGadget
2022-01-13 16:43 ` [PATCH 4/5] Update documentation related to sparsity and the skip-worktree bit Elijah Newren via GitGitGadget
2022-01-13 16:43 ` [PATCH 5/5] Accelerate clear_skip_worktree_from_present_files() by caching Elijah Newren via GitGitGadget
2022-01-13 23:35 ` Elijah Newren
2022-01-14 15:59 ` [PATCH v2 0/5] Remove the present-despite-SKIP_WORKTREE class of bugs (for sparse-checkouts) Elijah Newren via GitGitGadget
2022-01-14 15:59 ` [PATCH v2 1/5] t1011: add testcase demonstrating accidental loss of user modifications Elijah Newren via GitGitGadget
2022-02-16 8:51 ` Ævar Arnfjörð Bjarmason
2022-02-16 16:02 ` Elijah Newren
2022-01-14 15:59 ` [PATCH v2 2/5] unpack-trees: fix accidental loss of user changes Elijah Newren via GitGitGadget
2022-01-14 15:59 ` [PATCH v2 3/5] repo_read_index: clear SKIP_WORKTREE bit from files present in worktree Elijah Newren via GitGitGadget
2022-02-16 8:57 ` Ævar Arnfjörð Bjarmason
2022-02-16 16:08 ` Elijah Newren
2022-02-19 1:06 ` Jonathan Nieder
2022-02-19 16:42 ` Elijah Newren
2022-02-19 18:14 ` Jonathan Nieder
2022-02-20 5:28 ` Elijah Newren [this message]
2022-02-20 16:56 ` Derrick Stolee
2022-02-22 23:17 ` Jonathan Nieder
2022-01-14 15:59 ` [PATCH v2 4/5] Update documentation related to sparsity and the skip-worktree bit Elijah Newren via GitGitGadget
2022-02-16 9:15 ` Ævar Arnfjörð Bjarmason
2022-02-16 16:21 ` Elijah Newren
2022-01-14 15:59 ` [PATCH v2 5/5] Accelerate clear_skip_worktree_from_present_files() by caching Elijah Newren via GitGitGadget
2022-01-15 1:39 ` Victoria Dye
2022-02-16 9:32 ` Ævar Arnfjörð Bjarmason
2022-02-16 16:30 ` Elijah Newren
2022-02-17 4:40 ` Elijah Newren
2022-01-15 1:51 ` [PATCH v2 0/5] Remove the present-despite-SKIP_WORKTREE class of bugs (for sparse-checkouts) Victoria Dye
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=CABPp-BFEt1zxR6xoZmwmY2dtXkK+ti+g-1DHZCgeP2VpzWqqyA@mail.gmail.com \
--to=newren@gmail.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=lessleydennington@gmail.com \
--cc=stolee@gmail.com \
--cc=vdye@github.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).