On Wed, Jun 16, 2021 at 01:40:36PM +0900, Junio C Hamano wrote: > > Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes: > > +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. Ok. > > 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. Yeah, that is all correct. Ok, I will drop the broken suggestion. - Emily
