Re: Uninitialized submodules as symlinks

On Sat, Oct 8, 2016 at 2:59 AM, David Turner [off-list ref] wrote:

quoted

-----Original Message-----
From: Stefan Beller [mailto:sbeller@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 [off-list ref]
wrote:

quoted

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.

quoted

 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.
-- 
Duy