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.
On Thu, Oct 16, 2014 at 12:09 AM, Junio C Hamano [off-list ref] wrote:
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.
Originally I wanted to get it merged without submodule support, but I
failed to spot the local_repo_env problem and could have caused a
regression for submodules. So yeah delaying the series does not sound
bad. Not sure about the reroll (i.e. rewriting current patches). I
think putting patches on top with explanation is better. But we can
keep it in 'pu' and see if we really need to reroll.
--
Duy
Am 17.10.2014 um 11:14 schrieb Duy Nguyen:
On Thu, Oct 16, 2014 at 12:09 AM, Junio C Hamano [off-list ref] wrote:
quoted
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.
Originally I wanted to get it merged without submodule support, but I
failed to spot the local_repo_env problem and could have caused a
regression for submodules. So yeah delaying the series does not sound
bad. Not sure about the reroll (i.e. rewriting current patches). I
think putting patches on top with explanation is better. But we can
keep it in 'pu' and see if we really need to reroll.
I didn't look into your series in detail, but it looks to my like
excepting the .git/modules directory from sharing (by putting it
into local_repo_env array) and adding a test for that (just to be
sure that no modules directory shows up where it shouldn't) should
be sufficient to get your stuff merged without submodule support.
It might be better to handle submodule support in a follow up series.
Does that make sense?