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

From: Jens Lehmann <jens.lehmann@web.de>
Date: Oct 15, 2014, 18:57 UTC
Message-ID: <543EC390.4000709@web.de>
In-Reply-To: <20141014221509.GA10580@wheezy.local>

Am 15.10.2014 um 00:15 schrieb Max Kirillov:

Show 16 quoted lines

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

Show 7 quoted lines

>> 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?

Show 5 quoted lines

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

Show 17 quoted lines

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

Show 5 quoted lines

> $ 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).