From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: "Matti Möll" <Matti.Moell@opensynergy.com>,
"Junio C Hamano" <gitster@pobox.com>, "Jeff King" <peff@peff.net>,
"Jonas Bernoulli" <jonas@bernoul.li>,
git@vger.kernel.org
Subject: Re: "submodule foreach" much slower than removed "submodule--helper --list"
Date: Tue, 08 Nov 2022 04:37:55 +0100 [thread overview]
Message-ID: <221108.86tu3aru3d.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <Y2nD9AR8acaGLXDH@nand.local>
On Mon, Nov 07 2022, Taylor Blau wrote:
> On Mon, Nov 07, 2022 at 12:01:40PM +0100, Matti Möll wrote:
>> On 16.10.22 00:40, Junio C Hamano wrote:
>> >
>> > If one likes the output from "submodule--helper list" so much, I
>> > think your "ls-files" above should be the closest. There seems to
>> > have existed some logic to squash unmerged entries down to a single
>> > one, too (git-submodule.sh in Git 2.0.0 era has a module_list shell
>> > function that shows what "helper list" should be doing), though.
>>
>> I do actually like that submodule is hoisted out of the scripts but as a
>> matter of fact it seems that the openembedded folks relied on the
>> "submodule--helper list" call and with later git versions that doesn't work
>> anymore.
>>
>> https://github.com/openembedded/openembedded-core/commit/6d9364e5f3535954f65cbbc694ee7933ac1d664f
>>
>> At the end of the day it's kinda their fault to depend on the
>> submodule--helper but it does hinder adoption of new git versions for people
>> using openembedded.
>
> Yeah, I agree. It's unfortunate, but I think we consider anything with
> '--' in the builtin name to be outside of our compatibility guarantee.
>
> I recall a recent message on the list which where Junio said as much,
> but I can't seem to find it :-<.
We've never even documented it, so the uses that have been made of it
have been the result of source spelunking.
B.t.w. the openembedded commit above using "git config" is not going to
get the same results as "git submodule--helper list", or the equivalent
"git submodule foreach", but perhaps it works well enough for what they
need it for...
next prev parent reply other threads:[~2022-11-08 3:41 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-15 16:50 "submodule foreach" much slower than removed "submodule--helper --list" Jonas Bernoulli
2022-10-15 17:34 ` Jonas Bernoulli
2022-10-15 18:13 ` Jeff King
2022-10-15 18:16 ` Junio C Hamano
2022-10-15 18:23 ` Jeff King
2022-10-15 18:37 ` Junio C Hamano
2022-10-15 22:40 ` Junio C Hamano
2022-10-17 17:02 ` Jeff King
2022-11-07 11:01 ` Matti Möll
2022-11-08 2:50 ` Taylor Blau
2022-11-08 3:37 ` Ævar Arnfjörð Bjarmason [this message]
2022-10-17 16:50 ` Ævar Arnfjörð Bjarmason
2022-10-17 17:46 ` Jeff King
2022-10-21 14:58 ` Jonas Bernoulli
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=221108.86tu3aru3d.gmgdl@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=Matti.Moell@opensynergy.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jonas@bernoul.li \
--cc=me@ttaylorr.com \
--cc=peff@peff.net \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).