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

From: Max Kirillov <max@max630.net>
Date: Oct 14, 2014, 22:15 UTC
Message-ID: <20141014221509.GA10580@wheezy.local>
In-Reply-To: <543D7EBA.4040206@web.de>

On Tue, Oct 14, 2014 at 09:51:22PM +0200, Jens Lehmann wrote:

Show 12 quoted lines

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

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

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.

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

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

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.

Show 5 quoted lines

> Hmm, so I tend towards adding GIT_COMMON_DIR to
> local_repo_env until we figured out how to handle this.
> Without that I fear bad things will happen, at least for a
> superproject with multiple checkout-to work trees where
> the same submodule is initialized more than once ...

I learned about local_repo_env and agree it should include GIT_COMMON_DIR. Unless it is removed at all...