Re: "submodule foreach" much slower than removed "submodule--helper --list"

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

>   - the output of the old "submodule--helper list" looks a lot like
>     "ls-files" dumping the index and filtering on submodule entries.
>     Running:
>
>        git ls-files -s | grep ^160000
>
>     produces the same output.

Indeed that was what we wrote in the scripted Porcelain.  This is
one of the times I wish we didn't turn things to C in piecemeal.

> I'm not sure if those are exactly equivalent, either. It looks like the
> old code was probably respecting submodule active markers (though in my
> test repo without the submodule actually checked out, it's still
> reported).

"submodule--helper list" being the "give me the gitlinks", to be
filtered with things like pathspec and presence of .git (i.e. being
activated), you are right that those who liked the output from it
would not be happy with "foreach" anyway.  The comparison in the
original was apples and oranges because "foreach" should show only
the ones that are active in the current checkout.

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.

Thanks.