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

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 15.10.2014 um 00:15 schrieb Max Kirillov:
> On Tue, Oct 14, 2014 at 09:51:22PM +0200, Jens Lehmann wrote:
>> Am 14.10.2014 um 20:34 schrieb Max Kirillov:
>>> 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).
>>
>> Hmm, I'm not sure if this is a problem. If the
>> GIT_COMMON_DIR does have the submodule repo but it isn't
>> initialized locally, we shouldn't have a problem (except
>> for wasting some disk space if not a single checkout-to
>> superproject initializes this submodule).
>
> If initially a repository is clone without submodules, it
> will not have anything in the GIT_COMMON_DIR.

Ok.

>> And if GIT_COMMON_DIR does not have the submodule repo
>> yet, wouldn't it be cloned the moment we init the
>> submodule in the checkout-to? Or would that need extra
>> functionality?
>
> I cannot say I like this. Network operations should be
> caused only by clone and submodules.

Sure (and please add fetch to the list ;-). Maybe I confused
you by saying "init" when I meant the "submodule update" run
after initializing the submodule?

> I think the logic can be simple: it a submodule is not
> checked-out in the repository "checkout --to" is called
> from, then it is not checked-out to the new one also. If it
> is, then checkout calls itself recursively in the submodule
> and works like being run in standalone repository.

But when I later decide to populate the submodule in a
"checkout --to" work tree, should it automagically also
use the central storage, creating the modules/<name>
directory there if it doesn't exist yet? I think that'd
make sense to avoid having the work tree layout depend
on the order commands were ran in. And imagine new
submodules, they should not be handled differently from
those already present.

>>> 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.
>>
>> Maybe such configurations would have to be handled
>> manually to achieve maximum savings. At least I could live
>> with that.
>
> To make manual handling of the cases, and to skip
> checking-out a module.
>
> I would think about the following interface:
>
> $ git checkout --to ... - does not checkout submodules,
> creates empty directory.

This is what checkout should always do (at least until it
learns --recurse-submodules, then it would populate the
submodule directories).

> $ git checkout --recursive --to ... - if a submodule is
> checked-out in source repository, recursed there and run
> "checkout --recursive" again. If a submodule is not
> checked-out, does not checkout it, creates an empty
> directory.

Hmm, I believe that when the user requests recursion
explicitly it should always be checked out, no matter in
what state the GIT_COMMON_DIR is in. Otherwise we'll see
problems when a new submodule shows up and is populated
depending on the point in time the "checkout --to" was
done ... not good.

> By the way, I have found your branch
> recursive_submodule_checkout. Would you like to revive it?
> Then it can be done with the same option.

No need to revive it, I'm currently working on that branch
whenever I find some time (but I'll still need some time
before I can post the next iteration).