On Sat, Oct 8, 2016 at 2:59 AM, David Turner <david.tur...@twosigma.com> wrote:
>> -----Original Message-----
>> From: Stefan Beller [mailto:sbel...@google.com]
>> Sent: Friday, October 07, 2016 2:56 PM
>> To: David Turner
>> Cc: git@vger.kernel.org
>> Subject: Re: Uninitialized submodules as symlinks
>> On Fri, Oct 7, 2016 at 11:17 AM, David Turner <david.tur...@twosigma.com>
>> wrote:
>> > Presently, uninitialized submodules are materialized in the working tree
>> > as empty directories.
>> Right, there has to be something, to hint at the user that creating a file
>> with that path is probably not what they want.
>> >  We would like to consider having them be symlinks.  Specifically, we'd
>> > like them to be symlinks into a FUSE filesystem which retrieves files on
>> > demand.
>> >
>> > We've actually already got a FUSE filesystem written, but we use a
>> > different (semi-manual) means to connect it to the initialized submodules.
>> So you currently do a
>>     git submodule init <pathspec>
>>     custom-submodule make-symlink <pathspec>
>> ?
> We do something like
> For each initialized submodule: symlink it into the right place in .../somedir
> For each uninitialized submodule: symlink from the FUSE into the right place 
> in .../somedir
> So .../somedir has the structure of the git main repo, but is all symlinks -- 
> some into FUSE, some into the git repo.
> This means that when we initialize (or deinitialize) a submodule, we need to 
> re-run the linking script.

Do .git files work? If .git files point to somewhere in fuse, I guess
you still have file retrieval on demand. It depends on what files to
retrieve I guess. If you want worktree files, not object database then
.git files won't work because worktree remains in the same filesystem
as the super repo.

Reply via email to