> -----Original Message----- > From: Duy Nguyen [mailto:pclo...@gmail.com] > Sent: Monday, October 17, 2016 5:46 AM > To: David Turner > Cc: Stefan Beller; git@vger.kernel.org > Subject: Re: Uninitialized submodules as symlinks > > 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.
Yes, we want worktree files (or even worktree files + built artifacts).
