Re: What's cooking in git.git (Apr 2022, #04; Thu, 14)

[Emily Shaffer <emilyshaffer@google.com>]

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@chooglen-macbookpro.roam.corp.google.com>
>  source: <20220310004423.2627181-1-emilyshaffer@google.com>

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