ar/submodule-update (was Re: What's cooking in git.git (Jan 2022, #04; Fri, 14))

From: Glen Choo <chooglen@google.com>
Date: Jan 19, 2022, 00:38 UTC
Message-ID: <kl6llezcy2yr.fsf@chooglen-macbookpro.roam.corp.google.com>
In-Reply-To: <xmqqy23h4nss.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 16 quoted lines

> * ar/submodule-update (2021-10-13) 9 commits
>  . submodule--helper: rename helper functions
>  . submodule--helper: remove unused helpers
>  . submodule: move core cmd_update() logic to C
>  . submodule--helper: run update using child process struct
>  . submodule--helper: allow setting superprefix for init_submodule()
>  . submodule--helper: refactor get_submodule_displaypath()
>  . submodule--helper: rename helpers for update-clone
>  . submodule--helper: get remote names from any repository
>  . submodule--helper: split up ensure_core_worktree()
>
>  Rewrite of "git submodule update" in C.
>
>  Expecting a reroll?
>  cf. <YWiXL+plA7GHfuVv@google.com>
>  source: <20211013051805.45662-10-raykar.ath@gmail.com>

How close are we to getting this into 'next'? Last I checked, it seemed like the only remaining piece is to rebase this onto es/superproject-aware-submodules.

I have some planned work that will teach "git fetch" how to clone newly added submodules (this is the issue described in the BUGS section of Documentation/git-fetch.txt). That work will probably use the same machinery as `git submodule update`, so I'm wondering whether it's better to base this new work off ar/submodule-update or master.