Re: [RFC v1] Add virtual file system settings and hook proc
- From
Ben Peart <peartben@gmail.com>
- Date
- Nov 5, 2018, 20:27 UTC
- Message-ID
- <5f025224-ca28-4a93-495c-f866544ffc06@gmail.com>
- In-Reply-To
- <20181104210105.GK731755@genre.crustytoothpaste.net>
On 11/4/2018 4:01 PM, brian m. carlson wrote:
Show 31 quoted lines
> On Sun, Nov 04, 2018 at 07:34:01AM +0100, Duy Nguyen wrote: >> On Wed, Oct 31, 2018 at 9:53 PM Ben Peart <peartben@gmail.com> wrote: >>> It's more than a dynamic sparse-checkout because the same list is also >>> used to exclude any file/folder not listed. That means any file not >>> listed won't ever be updated by git (like in 'checkout' for example) so >>> 'stale' files could be left in the working directory. It also means git >>> won't find new/untracked files unless they are specifically added to the >>> list. >> >> OK. I'm not at all interested in carrying maintenance burden for some >> software behind closed doors. I could see values in having a more >> flexible sparse checkout but this now seems like very tightly designed >> for GVFS. So unless there's another use case (preferably open source) >> for this, I don't think this should be added in git.git. > > I should point out that VFS for Git is an open-source project and will > likely have larger use than just at Microsoft. There are both Windows > and Mac clients and there are plans for a Linux client as well. > Ideally, it would work with an unmodified upstream Git, which is (I > assume) why Ben is sending this series. > > Personally, I don't love the current name used in this series. I don't > see this patch as introducing a virtual file system in the Unix sense of > that word, and I think calling it that in Git core will be confusing to > Unix users. I would prefer to see it as a hook (maybe called > "sparse-checkout" or "sparse-exclude"; better names are okay), and > simply turn it on based on whether or not there's an appropriate hook > file there and whether core.sparseCheckout is on (or possibly with > hook.sparseExclude or something). With a design more like that, I don't > see a problem with it in principle. >
I'm really bad at naming so am happy to choose something else that will be more descriptive to the community at large. The name came from the fact that we started with the (equally awful) 'VFS for Git' and this was the big enabling feature in git so for better or worse it got saddled with the same 'VFS' name.
In other feedback it was suggested to not add a core.vfs setting that was the path to the hook and I like that. I can change it to core.sparseExclude (unless someone has something better) and hard code the hook name for now. I do like the idea of having config based hooks so when I get some time I will put together a patch series to implement that.