Re: [PATCH 0/4] Multiple worktrees vs. submodules fixes

[Max Kirillov <max@max630.net>]

On Tue, Oct 14, 2014 at 10:26:42AM -0700, Junio C Hamano wrote:
> And multiple-worktree _is_ about keeping the same repository and
> history data (i.e. object database, refs, rerere database, reflogs for
> refs/*) only once, while allowing multiple working trees attached to
> that single copy.
> 
> So it appears to me that to create a checkout-to copy of a
> superproject with a submodule, a checkout-to copy of the superproject
> would have a submodule, which is a checkout-to copy of the submodule
> in the superproject.

That's right, this linking should be more implicit.

But here are a lot of nuances. For example, it makes sense to have a
superproject checkout without submodules being initialized (so that they
don't waste space and machine time for working tree, which often is more
than repository data). And it may happen so that this checkout is the
master repository for superproject checkouts. But this should not
prevent users from using initialized submodules in other checkouts.

Then, a checkout copy of a submodule can be standalone (for example, git
and git-html-docs are submodules of msysgit). Or, it can even belong to
some other superproject. And in that cases they still should be able to
be linked.

Considering all above, and also the thing that I am quite new to
submodules (but have to use them currently), I did not intend to create
any new UI, only to make backend handle the already existing linked
checkouts, which can be made manually.

-- 
Max