Re: [RFC v1] Add virtual file system settings and hook proc

> On Mon, Nov 5, 2018 at 12:40 PM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:
>>
>>
>> On Sun, Nov 04 2018, Duy Nguyen wrote:
>>
>>> On Wed, Oct 31, 2018 at 9:53 PM Ben Peart <peartben@gmail.com> wrote:
>>>>>> +core.virtualFilesystem::
>>>>>> +       If set, the value of this variable is used as a command which
>>>>>> +       will identify all files and directories that are present in
>>>>>> +       the working directory.  Git will only track and update files
>>>>>> +       listed in the virtual file system.  Using the virtual file system
>>>>>> +       will supersede the sparse-checkout settings which will be ignored.
>>>>>> +       See the "virtual file system" section of linkgit:githooks[6].
>>>>>
>>>>> It sounds like "virtual file system" is just one of the use cases for
>>>>> this feature, which is more about a dynamic source of sparse-checkout
>>>>> bits. Perhaps name the config key with something along sparse checkout
>>>>> instead of naming it after a use case.
>>>>
>>>> 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 haven't looked at the patch in any detail beyond skimming it, and
>> you're more familiar with this area...
>>
>> But in principle I'm very interested in getting something like this in
>> git.git, even if we were to assume GVFS was a 100% proprietary
>> implementation.
> 
> I have nothing against building a GVFS-like solution. If what's
> submitted can be the building blocks for that, great! But if it was
> just for GVFS (and it was not available to everybody) then no thank
> you.
>