On Fri, Nov 05, 2021 at 09:51:12AM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>
> On Thu, Nov 04 2021, Emily Shaffer wrote:
>
> > A recorded hint path to the superproject's gitdir might be added during
> > 'git submodule add', but in some cases - like submodules which were
> > created before 'git submodule add' learned to record that info - it might
> > be useful to update the hint. Let's do it during 'git submodule
> > update', when we already have a handle to the superproject while calling
> > operations on the submodules.
> >
> > Signed-off-by: Emily Shaffer <emilyshaffer@xxxxxxxxxx>
> > ---
> > git-submodule.sh | 14 ++++++++++++++
> > t/t7406-submodule-update.sh | 12 ++++++++++++
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index 652861aa66..873d64eb99 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > @@ -449,6 +449,20 @@ cmd_update()
> > ;;
> > esac
> >
> > + # Cache a pointer to the superproject's common dir. This may have
> > + # changed, unless it's a fresh clone. Writes it to worktree
> > + # if applicable, otherwise to local.
> > + if test -z "$just_cloned"
> > + then
> > + sm_gitdir="$(git -C "$sm_path" rev-parse --absolute-git-dir)"
> > + relative_gitdir="$(git rev-parse --path-format=relative \
> > + --prefix "${sm_gitdir}" \
> > + --git-common-dir)"
> > +
> > + git -C "$sm_path" config --worktree \
> > + submodule.superprojectgitdir "$relative_gitdir"
> > + fi
> > +
>
> Aside from the "is this really needed anymore?" comment on this caching
> strategy in general I had in [1] does this really need to be adding new
> shell code to git-submodule.sh given that we're actively trying to get
> rid of it entirely and move it over to C.
>
> I.e. here we've just called "git submodule--helper
> run-update-procedure", and we pass it "$sm_path" (but not "$recursive",
> but could easily do so).
>
> It needs to clone this new submodule, so presumably it already has a
> "$sm_gitdir" equivalent, and we can turn that into the same relative
> path, no?
>
> Can't we call this with a git_config_set*() somewhere in that code?
>
> *investigates a bit*
>
> Okey, so I see that [2] is part of a series that Atharva Raykar had a
> version of (including this new git-submodule.sh code above) [3] rebased
> on top of an older version of this topic. I.e. this bit is that part of that patch:
>
> + git_config_set_in_file(config_path, "submodule.superprojectGitdir",
> + relative_path(get_git_dir(),
> + update_data->sm_path, &sb));
>
> I also vaguely recall that Junio ejected his topic to make room for this
> topic first.
>
> Maybe I've missed some update on this but is his [2][3] broken in
> combination with your topic here? And re[1] is whatever "caching" is
> being done here still beneficial once this is all moved to C?
>
> In your [4] there seems to be an agreement to do it the other way
> around, but as noted in the mail linked from [1] maybe the caching isn't
> needed anymore then?
I answered vs. your other mail; yes, it's still needed, and last I
checked Atharva's series had been kicked out to make room for this one.
>
> 1. https://lore.kernel.org/git/211105.861r3vhtot.gmgdl@xxxxxxxxxxxxxxxxxxx/
> 2. https://lore.kernel.org/git/20211013051805.45662-8-raykar.ath@xxxxxxxxx/
> 3. https://lore.kernel.org/git/20211013051805.45662-1-raykar.ath@xxxxxxxxx/
> 4. https://lore.kernel.org/git/YWiXL+plA7GHfuVv@xxxxxxxxxx/
