Re: [PATCH v2 2/4] introduce submodule.superprojectGitDir cache

[Junio C Hamano <gitster@pobox.com>]

Emily Shaffer <emilyshaffer@google.com> writes:

> Teach submodules a reference to their superproject's gitdir. This allows
> us to A) know that we're running from a submodule, and B) have a
> shortcut to the superproject's vitals, for example, configs.
>
> By using a relative path instead of an absolute path, we can move the
> superproject directory around on the filesystem without breaking the
> submodule's cache.
>
> Since this cached value is only introduced during new submodule creation
> via `git submodule add`, though, there is more work to do to allow the
> cache to be created at other times.
>
> Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
> ---
>  Documentation/config/submodule.txt | 12 +++++++++
>  builtin/submodule--helper.c        |  4 +++
>  t/t7400-submodule-basic.sh         | 40 ++++++++++++++++--------------
>  3 files changed, 38 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/config/submodule.txt b/Documentation/config/submodule.txt
> index d7a63c8c12..7c459cc19e 100644
> --- a/Documentation/config/submodule.txt
> +++ b/Documentation/config/submodule.txt
> @@ -90,3 +90,15 @@ submodule.alternateErrorStrategy::
>  	`ignore`, `info`, `die`. Default is `die`. Note that if set to `ignore`
>  	or `info`, and if there is an error with the computed alternate, the
>  	clone proceeds as if no alternate was specified.
> +
> +submodule.superprojectGitDir::
> +	The relative path from the submodule's worktree  to the superproject's
> +	gitdir. This config should only be present in projects which are
> +	submodules, but is not guaranteed to be present in every submodule. It
> +	is set automatically during submodule creation.
> ++
> +	In situations where more than one superproject references the same
> +	submodule worktree, the value of this config and the behavior of
> +	operations which use it are undefined. To reference a single project
> +	from multiple superprojects, it is better to create a worktree of the
> +	submodule for each superproject.

You'd need to dedent the second paragraph that follows a lone '+'
sign to typeset this correctly.

The new paragraph suggests separate worktrees for the same submodule
repository, but for that to work correctly,

 - "git clone [--recurse-submodules]" that clones the second
   superproject that shares the same submodule with a superproject
   that we already locally has to support a way for users to tell
   where to grab that existing submodule from and arrange a new
   worktree, instead of creating another instance of the submodule
   repository by cloning it afresh.

 - The "submodule.superprojectGitDir" needs to be set to
   per-worktree half of the repo-local configuration file.

Because I usually do not pay much attention to the submodule part of
the toolset, I may well be mistaken, but I suspect that the former
does not exist yet.  If I recall correctly, the latter was a NEEDSWORK
item in the previous round of this patchset?

As I said, I think it is OK for now to stop at declaring that you
cannot simply do it without hinting something that may not fully
work.

Thanks.