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

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

Am 14.10.2014 um 20:34 schrieb Max Kirillov:

quoted

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.

quoted

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.

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