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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 15, 2022, 22:40 UTC
Message-ID: <xmqqwn904sof.fsf@gitster.g>
In-Reply-To: <Y0r4US7AKxT/BLiY@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 7 quoted lines

>   - 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.