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

Duy Nguyen [off-list ref] writes:

On Wed, Oct 15, 2014 at 3:31 AM, Max Kirillov [off-list ref] wrote:

quoted

On Tue, Oct 14, 2014 at 07:09:45PM +0200, Jens Lehmann wrote:

quoted

Until that problem is solved it looks wrong to pass
GIT_COMMON_DIR into submodule recursion, I believe
GIT_COMMON_DIR should be added to the local_repo_env array
(and even if it is passed on later, we might have to
append "/modules/<submodule_name>" to make it point to the
correct location).

Actually, why there should be an _environment_ variable
GIT_COMMON_DIR at all? I mean, gitdir is resolved to some
directory (through link or environment), and it contains the
shared data directly or referes to it with the commondir
link. In which case anyone would want to override that
location?

It's how the implementation was built up. First I split the repo in
two and I need something to point the new/shared part.
$GIT_DIR/worktrees comes later to glue them up. Keeping it an
environment variable gives us a possibility to glue things up in a
different way than using $GIT_DIR/worktrees. Of course the odds of
anybody doing that are probably small or even near zero.

Still consuming the rest of this thread. Thanks all for working on the
submodule support for this.

Hmph.  I was hoping that the multiple-work-trees topic was ready for
'next' by now, but we may want to wait to see how the interaction
with submodule plays out to have another chance of a clean reroll
before it happens.  This is a topic with large impact and is quite
intrusive code-wise, even though the intrusive parts are cleanly
done.  So we'd want to take more time to unleash it to the general
public than more usual small scale topics, anyway.

Thanks.