Re: git submodules

[Junio C Hamano <gitster@pobox.com>]

Pierre Habouzit <madcoder@debian.org> writes:

> On Mon, Jul 28, 2008 at 10:41:17PM +0000, Junio C Hamano wrote:
>
>> I suspect the use of it may help the use case Pierre proposes, but its
>> main attractiveness as I understood it back when we discussed the facility
>> was that you could switch branches between 'maint' that did not have a
>> submodule at "path" back then, and 'master' that does have one now,
>> without losing the submodule repository.  When checking out 'master' (and
>> that would probably mean you would update 'git-submodule init' and
>> 'git-submodule update' implementation), you would instanciate subdirectory
>> "path", create "path/.git" that is such a regular file that that points at
>> somewhere inside the $GIT_DIR of superproject (say ".git/submodules/foo").
>> By storing refs and object store are all safely away in the superproject
>> $GIT_DIR, you can now safely switch back to 'maint', which would involve
>> making sure there is no local change that will be lost and then removing
>> the "path" and everything underneath it.
>
> gitfiles looks nifty for sure, though I've thought about it a bit, and
> I'm not sure if we don't want something a bit more powerful, though
> still in the same vein.
>
> If we look at submodules, I quite believe that we would benefit a lot
> from sharing the object directory accross the supermodule and all its
> submodules, because of the following reasons:

I know there are cases where sharing object store is useful.  Being able
to share is one thing.  Always having to share, without any other option,
is another.

Using gitlink to keep the true repository data out of submodule checkout
area so that branch switching can safely be done is orthogonal to the
issue of how repositories of submodules and the superproject share their
object store.  IOW, you would always use gitlink to solve the "branch
switching may make the submodule checkout disappear" issue, while you
could use alternates mechanism (or direct symlinking of $GIT_DIR/objects)
across these repositories *if* you want to share their object store.

> Though we would not like to have submodules suffer from reachability
> issues after a prune in the supermodule. That means that all references
> and reflogs of the submodules shall be accessible from the supermodule
> so that everything that could mess with the object store by removing
> objects cannot remove interesting objects (that should limit the code
> paths to really seldom places actually).

I do not think this issue is limited to use of submodules.  I'd imagine
that if you build this reachability protection into the alternates
mechanism, you would automatically solve both "multiple checkout of the
same project, via git-new-workdir" issue as well as "submodules that share
its objects with the superproject" issue.

Which leads me to conclude, at least for now, that it would not be a good
idea to make this related to gitfile in any way.  Object sharing between
equal repositories (aka new-workdir) does not use gitfile, but it still
needs to have the same kind of reachability protection.