On Sat, Oct 15, 2022 at 06:50:36PM +0200, Jonas Bernoulli wrote:
> > 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
