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

From: Jeff King <peff@peff.net>
Date: Oct 15, 2022, 18:13 UTC
Message-ID: <Y0r4US7AKxT/BLiY@coredump.intra.peff.net>
In-Reply-To: <87a65xrnwz.fsf@bernoul.li>

On Sat, Oct 15, 2022 at 06:50:36PM +0200, Jonas Bernoulli wrote:

Show 16 quoted lines

> > We're not getting anything useful from the "list | cut -f2"
> > invocation that we couldn't get from "foreach 'echo $sm_path'".
> 
> But we get speed (this is with about one hundred modules):
> 
> $ time git submodule foreach -q 'echo $sm_path' > /dev/null
> 
> real    0m0.585s
> user    0m0.413s
> sys     0m0.182s
> 
> $ time git submodule--helper list > /dev/null
> 
> real    0m0.008s
> user    0m0.004s
> sys     0m0.004s

Yeah, that's not too surprising that it's slower. It's exec-ing a bunch of shells to do that.

I don't really use submodules and haven't worked much on them either, but maybe one of these works:

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

  - If you just want the oid/path of each, then "git submodule status"
    prints those. You might want "--cached" to avoid spending extra time
    checking the status (though it kind of looks like we may run "git
    describe" in each anyway; yikes!)

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). There is probably room for a user-facing "git submodule list" command, but again, I don't really know enough about the space to say what it should report.

-Peff