After quite some time, I'll provide an update on the "submodules UX rework" effort Google has been working on. On Thu, Apr 14, 2022 at 05:06:26PM -0700, Junio C Hamano wrote: > [Stalled] > * es/superproject-aware-submodules (2022-03-09) 3 commits > . rev-parse: short-circuit superproject worktree when config unset > . introduce submodule.hasSuperproject record > . t7400-submodule-basic: modernize inspect() helper > > A configuration variable in a repository tells if it is (or is not) > a submodule of a superproject. > > Expecting a reroll. > cf. <kl6l4k45s7cb.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> > source: <20220310004423.2627181-1-emilyshaffer@xxxxxxxxxx> Yes, a reroll is planned. The most recent attempt (locally) also rerolled a follow-on series adding a shared "config.superproject" readable by both a superproject and its submodules, in order to demonstrate some real-world application and an example of how to use this config telling us whether or not we're a submodule. The series has gotten away from me - as I've been working on internal team planning type things. Beyond this work, there is some other work in progress, still in design stages downstream: Glen Choo is continuing work on design for 'git checkout -b'/'git switch -c' when submodules are involved and 'submodule.recurse' is set. Glen Choo sent an update to continue converting 'git submodule update' into C; this appears to have no reviews. https://lore.kernel.org/git/20220315210925.79289-1-chooglen%40google.com Josh Steadmon is working on design for 'git pull --rebase --recurse-submodules' in basic (non-conflicting) cases; this means he's also working on 'git rebase --recurse-submodules' in these same basic cases. This work is still fairly early in the design stage, but will be something to look forward to. Beyond those pieces, I thought it might be interesting for me to share what's coming up for my team from April through June. So here's a grab bag of what's next for us: - Improving 'git fetch --recurse-submodules': * To retry a failed submodule more than once (in fact, the existing behavior seems to have a bug: if we fail to clone a submodule in the "retry queue", we give up and don't try to clone any of the other retryable submodules after that one) * Cloning submodules that were added in a commit which is newly fetched with 'git fetch' - Parallelizing 'git checkout --recurse-submodules' (at least when partial clones are involved). Without this change, we see that the initial checkout of a partial-cloned repo with many submodules takes a long, long, long time. - Parallelizing 'git status --recurse-submodules' when many submodules are involved (and probably tidying the output) And some more odds and ends. After those few bits, and the in-progress work already seen on the list, we have some users lined up to try the workflow, because we're pretty sure that puts us in a position to try out basic Git usage with many submodules. So hopefully we have some interesting feedback and bug fixes coming from that, as well. - Emily
