Duy Nguyen <pclouds@xxxxxxxxx> writes: > On Wed, Oct 15, 2014 at 3:31 AM, Max Kirillov <max@xxxxxxxxxx> wrote: >> On Tue, Oct 14, 2014 at 07:09:45PM +0200, Jens Lehmann wrote: >>> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html