From: <rsbecker@nexbridge.com>
To: "'Emily Shaffer'" <emilyshaffer@google.com>,
"'Junio C Hamano'" <gitster@pobox.com>
Cc: <git@vger.kernel.org>
Subject: RE: What's cooking in git.git (Apr 2022, #04; Thu, 14)
Date: Fri, 15 Apr 2022 18:53:41 -0400 [thread overview]
Message-ID: <00a001d8511b$aa547c20$fefd7460$@nexbridge.com> (raw)
In-Reply-To: <YlnzGecOaayPM6ve@google.com>
On April 15, 2022 6:35 PM, Emily Shaffer wrote:
>After quite some time, I'll provide an update on the "submodules UX rework"
>effort Google has been working on.
I'm looking forward to being able to test this extensively. This has
interest in my community.
>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
prev parent reply other threads:[~2022-04-15 22:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-15 0:06 What's cooking in git.git (Apr 2022, #04; Thu, 14) Junio C Hamano
2022-04-15 22:35 ` Emily Shaffer
2022-04-15 22:53 ` rsbecker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='00a001d8511b$aa547c20$fefd7460$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).