On 8/19/2021 4:09 PM, Emily Shaffer wrote:
> + # Cache a pointer to the superproject's gitdir. This may have
> + # changed, so rewrite it unconditionally. Writes it to worktree
> + # if applicable, otherwise to local.
> + relative_gitdir="$(git rev-parse --path-format=relative \
> + --prefix "${sm_path}" \
> + --git-dir)"
> +
> + git -C "$sm_path" config --worktree \> + submodule.superprojectgitdir "$relative_gitdir"
Ok, I see now why you care about the worktree config. The scenario you
are covering is something like moving a submodule within a worktree and
not wanting to change the relative path of other copies of that submodule
within other worktrees, yes?
For commands such as 'init' and 'add', we don't have the possibility of
colliding with other worktrees because the submodule is being created
for the first time, so the relative path should be safe to place in the
non-worktree config.
I do struggle with the fact that these are inconsistent across the
two commits. It makes me think that there should only be one way to
do it, and either the NEEDSWORK needs to be fixed now, or this line
shouldn't include --worktree. Much of this can depend on the reason
the worktree config exists for a submodule. I expect you have more
context than me, so could you help me understand?
Moving to a different concern I am now realizing with this config:
What happens if a submodule moves, and then a user runs 'git checkout'
in the superproject to move it back? How do we make this config value
update across those movements? Is there a possibility of integrating
with unpack_trees() to notice that a submodule has moved and hence we
should update this config value?
Thanks,
-Stoolee
