Sorry for going silent right after bringing this up. Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > I can't reproduce anything like the 8ms v.s. ~600ms difference you note > here, but for me migrating it to a built-in is around 10% slower with > "foreach" than the old "list". I wonder what results you get? The repository, in which I observed this slowdown, has one hundred modules. > I sent in a topic to migrate it since you sent this report. I was going > to do it in this development cycle, but this prompted me to do it > earlier: Thanks! A lot more is happening here than I can quickly understand, but the last commit mentions that the slowdown is now just 0.1, which would be good enough for me, I think. > On Sat, Oct 15 2022, Jonas Bernoulli wrote: > >> I just noticed that "submodule--helper name" was also removed, which I >> also found useful in scripts. Please tell me if I am missing something, >> but it seems I now have to do something like this instead: >> >> git config -f .gitmodules --list | >> sed -n "s|^submodule.\([^.]*\).path=$path\$|\1|p" >> >> The old way was nicer: >> >> git submodule--helper name $path >> >> I realize submodule--helper is for internal use and using it anyway >> comes with the risk of such removals and other changes, but again, >> please consider restoring that or providing something similar in the >> public interface. > > This however is another case, I removed "name" along with "list" and > other leftover code we weren't using anymore for the internal-only > "submodule--helper" (which is at turns out, was not as internal-only as > we'd hoped). > > For "list" it's clear how to use "foreach" instead, but for "name" then > AFAICT the "best" replacement is to do a: > > git submodule foreach 'echo $displaypath $name' > > And pipe that into grep/sed. If that's fast enough would it satisfy your > use-case, or would a "name" equivalent be handy? > > I think the best way to prove that would be e.g.: > > git submodule foreach-format '%{name}' -- <pathspec> > > Which, due to the "foreach" taking N number of arguments isn't easy to > add to "foreach" without the interface becoming somewhat tortured (we > could add a [---pathspec=<pathspec>]...), but "-- <pathspec>" with a > different subcommand name seems better. I agree, that adding support for "-- <pathspec>" to an existing or new subcommand, would make it unnecessary to bring back a "name" subcommand. Will "foreach"/"foreach-format" continue to be limited to active modules? Sometimes it would be nice to list all modules, including those that are inactive. As mentioned earlier "git ls-files -s | grep ^160000" is enough to get a list of the module paths, but sometimes we want more information, e.g., "git submodule list --include-inactive --format '$name $is_active submodule.$name.url' -- <pathspec>". Jonas