{"thread":{"id":"58629","subject":"\"submodule foreach\" much slower than removed \"submodule--helper --list\"","startedAt":"2022-10-15T16:56:10Z","lastAt":"2022-11-08T03:41:32Z","messageCount":14,"participants":["Jonas Bernoulli","Jeff King","Junio C Hamano","Ævar Arnfjörð Bjarmason","Matti Möll","Taylor Blau"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"465021","messageId":"87czatrpyb.fsf@bernoul.li","threadId":"58629","inReplyTo":null,"subject":"\"submodule foreach\" much slower than removed \"submodule--helper --list\"","fromName":"Jonas Bernoulli","fromEmail":"jonas@bernoul.li","sentAt":"2022-10-15T16:50:36Z","receivedAt":"2022-10-15T16:56:10Z","isPatch":false,"sender":{"key":"jonas@bernoul.li","avatar":"https://gravatar.com/avatar/67252b2d3a6aacebe15776a6c0cb26c78b475dedc8410caa8765f1f4953222aa?d=mp&s=160"},"body":"In v2.38.0 (31955475d1c283120d5d84247eb3fd55d9f5fdd9)\n\"submodule--helper --list\" was remove because\n\n> We're not getting anything useful from the \"list | cut -f2\"\n> invocation that we couldn't get from \"foreach 'echo $sm_path'\".\n\nBut we get speed (this is with about one hundred modules):\n\n$ time git submodule foreach -q 'echo $sm_path' > /dev/null\n\nreal 0m0.585s\nuser 0m0.413s\nsys 0m0.182s\n\n$ time git submodule--helper list > /dev/null\n\nreal 0m0.008s\nuser 0m0.004s\nsys 0m0.004s\n\nPlease consider restoring this subcommand or providing something\nequivalent that is just as fast.\n\n Thanks,\n Jonas\n"},{"id":"465022","messageId":"87a65xrnwz.fsf@bernoul.li","threadId":"58629","inReplyTo":"87czatrpyb.fsf@bernoul.li","subject":"Re: \"submodule foreach\" much slower than removed \"submodule--helper --list\"","fromName":"Jonas Bernoulli","fromEmail":"jonas@bernoul.li","sentAt":"2022-10-15T17:34:36Z","receivedAt":"2022-10-15T17:35:03Z","isPatch":false,"sender":{"key":"jonas@bernoul.li","avatar":"https://gravatar.com/avatar/67252b2d3a6aacebe15776a6c0cb26c78b475dedc8410caa8765f1f4953222aa?d=mp&s=160"},"body":"I just noticed that \"submodule--helper name\" was also removed, which I\nalso found useful in scripts. Please tell me if I am missing something,\nbut it seems I now have to do something like this instead:\n\n git config -f .gitmodules --list |\n sed -n \"s|^submodule.\\([^.]*\\).path=$path\\$|\\1|p\"\n\nThe old way was nicer:\n\n git submodule--helper name $path\n\nI realize submodule--helper is for internal use and using it anyway\ncomes with the risk of such removals and other changes, but again,\nplease consider restoring that or providing something similar in the\npublic interface.\n\n Cheers,\n Jonas\n"},{"id":"465024","messageId":"Y0r4US7AKxT/BLiY@coredump.intra.peff.net","threadId":"58629","inReplyTo":"87a65xrnwz.fsf@bernoul.li","subject":"Re: \"submodule foreach\" much slower than removed \"submodule--helper --list\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-10-15T18:13:37Z","receivedAt":"2022-10-15T18:13:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 15, 2022 at 06:50:36PM +0200, Jonas Bernoulli wrote:\n\n> > We're not getting anything useful from the \"list | cut -f2\"\n> > invocation that we couldn't get from \"foreach 'echo $sm_path'\".\n> \n> But we get speed (this is with about one hundred modules):\n> \n> $ time git submodule foreach -q 'echo $sm_path' > /dev/null\n> \n> real 0m0.585s\n> user 0m0.413s\n> sys 0m0.182s\n> \n> $ time git submodule--helper list > /dev/null\n> \n> real 0m0.008s\n> user 0m0.004s\n> sys 0m0.004s\n\nYeah, that's not too surprising that it's slower. It's exec-ing a bunch\nof shells to do that.\n\nI don't really use submodules and haven't worked much on them either,\nbut maybe one of these works:\n\n - the output of the old \"submodule--helper list\" looks a lot like\n \"ls-files\" dumping the index and filtering on submodule entries.\n Running:\n\n git ls-files -s | grep ^160000\n\n produces the same output.\n\n - If you just want the oid/path of each, then \"git submodule status\"\n prints those. You might want \"--cached\" to avoid spending extra time\n checking the status (though it kind of looks like we may run \"git\n describe\" in each anyway; yikes!)\n\nI'm not sure if those are exactly equivalent, either. It looks like the\nold code was probably respecting submodule active markers (though in my\ntest repo without the submodule actually checked out, it's still\nreported). There is probably room for a user-facing \"git submodule list\"\ncommand, but again, I don't really know enough about the space to say\nwhat it should report.\n\n-Peff\n"},{"id":"465026","messageId":"xmqqilkl54wp.fsf@gitster.g","threadId":"58629","inReplyTo":"Y0r4US7AKxT/BLiY@coredump.intra.peff.net","subject":"Re: \"submodule foreach\" much slower than removed \"submodule--helper --list\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-15T18:16:06Z","receivedAt":"2022-10-15T18:16:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Yeah, that's not too surprising that it's slower. It's exec-ing a bunch\n> of shells to do that.\n> ...\n> I'm not sure if those are exactly equivalent, either. It looks like the\n> old code was probably respecting submodule active markers (though in my\n> test repo without the submodule actually checked out, it's still\n> reported). There is probably room for a user-facing \"git submodule list\"\n> command, but again, I don't really know enough about the space to say\n> what it should report.\n\nWe could mimic \"find\" and make \"foreach\" that has no action default\nto an equivalent of \"echo\" that is done internally without forking.\n\n"},{"id":"465028","messageId":"Y0r6iAv1OVUVYNGc@coredump.intra.peff.net","threadId":"58629","inReplyTo":"xmqqilkl54wp.fsf@gitster.g","subject":"Re: \"submodule foreach\" much slower than removed \"submodule--helper --list\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-10-15T18:23:04Z","receivedAt":"2022-10-15T18:23:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 15, 2022 at 11:16:06AM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Yeah, that's not too surprising that it's slower. It's exec-ing a bunch\n> > of shells to do that.\n> > ...\n> > I'm not sure if those are exactly equivalent, either. It looks like the\n> > old code was probably respecting submodule active markers (though in my\n> > test repo without the submodule actually checked out, it's still\n> > reported). There is probably room for a user-facing \"git submodule list\"\n> > command, but again, I don't really know enough about the space to say\n> > what it should report.\n> \n> We could mimic \"find\" and make \"foreach\" that has no action default\n> to an equivalent of \"echo\" that is done internally without forking.\n\nThat would be reasonable to me, though I wonder what the output format\nshould be. Just name, or name/oid? Once you start having options, you\nmight as well just add a separate \"git submodule list\" that can take\nthem.\n\n-Peff\n"},{"id":"465031","messageId":"xmqq35bp53xg.fsf@gitster.g","threadId":"58629","inReplyTo":"Y0r6iAv1OVUVYNGc@coredump.intra.peff.net","subject":"Re: \"submodule foreach\" much slower than removed \"submodule--helper --list\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-15T18:37:15Z","receivedAt":"2022-10-15T18:37:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> We could mimic \"find\" and make \"foreach\" that has no action default\n>> to an equivalent of \"echo\" that is done internally without forking.\n>\n> That would be reasonable to me, though I wonder what the output format\n> should be. Just name, or name/oid? Once you start having options, you\n> might as well just add a separate \"git submodule list\" that can take\n> them.\n\nUsers of \"find\" seem to be happy with \"-print\" being the default, so\nwhatever we were doing with the internal \"helper --list\" would be\nappropriate here. Folks who want different output can feed their\nown action.\n"},{"id":"465036","messageId":"xmqqwn904sof.fsf@gitster.g","threadId":"58629","inReplyTo":"Y0r4US7AKxT/BLiY@coredump.intra.peff.net","subject":"Re: \"submodule foreach\" much slower than removed \"submodule--helper --list\"","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-10-15T22:40:16Z","receivedAt":"2022-10-15T22:40:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> - the output of the old \"submodule--helper list\" looks a lot like\n> \"ls-files\" dumping the index and filtering on submodule entries.\n> Running:\n>\n> git ls-files -s | grep ^160000\n>\n> produces the same output.\n\nIndeed that was what we wrote in the scripted Porcelain. This is\none of the times I wish we didn't turn things to C in piecemeal.\n\n> I'm not sure if those are exactly equivalent, either. It looks like the\n> old code was probably respecting submodule active markers (though in my\n> test repo without the submodule actually checked out, it's still\n> reported).\n\n\"submodule--helper list\" being the \"give me the gitlinks\", to be\nfiltered with things like pathspec and presence of .git (i.e. being\nactivated), you are right that those who liked the output from it\nwould not be happy with \"foreach\" anyway. The comparison in the\noriginal was apples and oranges because \"foreach\" should show only\nthe ones that are active in the current checkout.\n\nIf one likes the output from \"submodule--helper list\" so much, I\nthink your \"ls-files\" above should be the closest. There seems to\nhave existed some logic to squash unmerged entries down to a single\none, too (git-submodule.sh in Git 2.0.0 era has a module_list shell\nfunction that shows what \"helper list\" should be doing), though.\n\nThanks.\n\n"},{"id":"465112","messageId":"221017.86h702jsiq.gmgdl@evledraar.gmail.com","threadId":"58629","inReplyTo":"87a65xrnwz.fsf@bernoul.li","subject":"Re: \"submodule foreach\" much slower than removed \"submodule--helper --list\"","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-10-17T16:50:06Z","receivedAt":"2022-10-17T16:59:16Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nReplying to both this & the parent post:\n\nOn Sat, Oct 15 2022, Jonas Bernoulli wrote:\n\n> In v2.38.0 (31955475d1c283120d5d84247eb3fd55d9f5fdd9)\n> \"submodule--helper --list\" was remove because\n>\n>> We're not getting anything useful from the \"list | cut -f2\"\n>> invocation that we couldn't get from \"foreach 'echo $sm_path'\".\n>\n> But we get speed (this is with about one hundred modules):\n>\n> $ time git submodule foreach -q 'echo $sm_path' > /dev/null\n>\n> real 0m0.585s\n> user 0m0.413s\n> sys 0m0.182s\n>\n> $ time git submodule--helper list > /dev/null\n>\n> real 0m0.008s\n> user 0m0.004s\n> sys 0m0.004s\n>\n> Please consider restoring this subcommand or providing something\n> equivalent that is just as fast.\n\nSorry about the slowdown, the removal of \"list\" was just an in-between\nstep to migrating \"submodule\" to a full built-in.\n\nI can't reproduce anything like the 8ms v.s. ~600ms difference you note\nhere, but for me migrating it to a built-in is around 10% slower with\n\"foreach\" than the old \"list\". I wonder what results you get?\n\nI sent in a topic to migrate it since you sent this report. I was going\nto do it in this development cycle, but this prompted me to do it\nearlier:\n\n\thttps://lore.kernel.org/git/cover-00.10-00000000000-20221017T115544Z-avarab@gmail.com/\n\nOn Sat, Oct 15 2022, Jonas Bernoulli wrote:\n\n> I just noticed that \"submodule--helper name\" was also removed, which I\n> also found useful in scripts. Please tell me if I am missing something,\n> but it seems I now have to do something like this instead:\n>\n> git config -f .gitmodules --list |\n> sed -n \"s|^submodule.\\([^.]*\\).path=$path\\$|\\1|p\"\n>\n> The old way was nicer:\n>\n> git submodule--helper name $path\n>\n> I realize submodule--helper is for internal use and using it anyway\n> comes with the risk of such removals and other changes, but again,\n> please consider restoring that or providing something similar in the\n> public interface.\n\nThis however is another case, I removed \"name\" along with \"list\" and\nother leftover code we weren't using anymore for the internal-only\n\"submodule--helper\" (which is at turns out, was not as internal-only as\nwe'd hoped).\n\nFor \"list\" it's clear how to use \"foreach\" instead, but for \"name\" then\nAFAICT the \"best\" replacement is to do a:\n\n\tgit submodule foreach 'echo $displaypath $name'\n\nAnd pipe that into grep/sed. If that's fast enough would it satisfy your\nuse-case, or would a \"name\" equivalent be handy?\n\nI think the best way to prove that would be e.g.:\n\n\tgit submodule foreach-format '%{name}' -- \n\nWhich, due to the \"foreach\" taking N number of arguments isn't easy to\nadd to \"foreach\" without the interface becoming somewhat tortured (we\ncould add a [---pathspec=]...), but \"-- \" with a\ndifferent subcommand name seems better.\n"},{"id":"465114","messageId":"Y02KtjAUGSPqffvB@coredump.intra.peff.net","threadId":"58629","inReplyTo":"xmqqwn904sof.fsf@gitster.g","subject":"Re: \"submodule foreach\" much slower than removed \"submodule--helper --list\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-10-17T17:02:46Z","receivedAt":"2022-10-17T17:02:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 15, 2022 at 03:40:16PM -0700, Junio C Hamano wrote:\n\n> If one likes the output from \"submodule--helper list\" so much, I\n> think your \"ls-files\" above should be the closest. There seems to\n> have existed some logic to squash unmerged entries down to a single\n> one, too (git-submodule.sh in Git 2.0.0 era has a module_list shell\n> function that shows what \"helper list\" should be doing), though.\n\nAh, good digging. I briefly looked at the patch removing the\nsubmodule--helper version, saw the word \"active\", and assumed it was\nchecking that. On closer inspection, it is just the global \"active_nr\"\nfor iterating over the index. ;)\n\nSo yeah, using \"ls-files\" is a suitable replacement for Jonas's original\ncomplaint. I'll leave it up to folks more interested and knowledgeable\non submodules to discuss whether there ought to be a listing command\nthat's more aware of gitmodules, populated fields, active flags, etc.\n\n-Peff\n"},{"id":"465119","messageId":"Y02U7611DH6zFsK9@coredump.intra.peff.net","threadId":"58629","inReplyTo":"221017.86h702jsiq.gmgdl@evledraar.gmail.com","subject":"Re: \"submodule foreach\" much slower than removed \"submodule--helper --list\"","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2022-10-17T17:46:23Z","receivedAt":"2022-10-17T17:46:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 17, 2022 at 06:50:06PM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> Sorry about the slowdown, the removal of \"list\" was just an in-between\n> step to migrating \"submodule\" to a full built-in.\n> \n> I can't reproduce anything like the 8ms v.s. ~600ms difference you note\n> here, but for me migrating it to a built-in is around 10% slower with\n> \"foreach\" than the old \"list\". I wonder what results you get?\n\nI don't think \"foreach\" can ever be as performant as a bare \"list\". It\ninherently is going to do O(n) fork+execs. So it's OK if you have one or\ntwo submodules, but not if you have hundreds.\n\nIf it treated \"echo\" as a builtin and served it in-process, it could\navoid that extra overhead. But there are so many corner cases there,\nyou'd probably do better to add \"list --format\" instead.\n\n-Peff\n"},{"id":"465467","messageId":"87k04tfcle.fsf@bernoul.li","threadId":"58629","inReplyTo":"221017.86h702jsiq.gmgdl@evledraar.gmail.com","subject":"Re: \"submodule foreach\" much slower than removed \"submodule--helper --list\"","fromName":"Jonas Bernoulli","fromEmail":"jonas@bernoul.li","sentAt":"2022-10-21T14:58:05Z","receivedAt":"2022-10-21T14:58:12Z","isPatch":false,"sender":{"key":"jonas@bernoul.li","avatar":"https://gravatar.com/avatar/67252b2d3a6aacebe15776a6c0cb26c78b475dedc8410caa8765f1f4953222aa?d=mp&s=160"},"body":"Sorry for going silent right after bringing this up.\n\nÆvar Arnfjörð Bjarmason writes:\n\n> I can't reproduce anything like the 8ms v.s. ~600ms difference you note\n> here, but for me migrating it to a built-in is around 10% slower with\n> \"foreach\" than the old \"list\". I wonder what results you get?\n\nThe repository, in which I observed this slowdown, has one hundred\nmodules.\n\n> I sent in a topic to migrate it since you sent this report. I was going\n> to do it in this development cycle, but this prompted me to do it\n> earlier:\n\nThanks!\n\nA lot more is happening here than I can quickly understand, but the last\ncommit mentions that the slowdown is now just 0.1, which would be good\nenough for me, I think.\n\n> On Sat, Oct 15 2022, Jonas Bernoulli wrote:\n>\n>> I just noticed that \"submodule--helper name\" was also removed, which I\n>> also found useful in scripts. Please tell me if I am missing something,\n>> but it seems I now have to do something like this instead:\n>>\n>> git config -f .gitmodules --list |\n>> sed -n \"s|^submodule.\\([^.]*\\).path=$path\\$|\\1|p\"\n>>\n>> The old way was nicer:\n>>\n>> git submodule--helper name $path\n>>\n>> I realize submodule--helper is for internal use and using it anyway\n>> comes with the risk of such removals and other changes, but again,\n>> please consider restoring that or providing something similar in the\n>> public interface.\n>\n> This however is another case, I removed \"name\" along with \"list\" and\n> other leftover code we weren't using anymore for the internal-only\n> \"submodule--helper\" (which is at turns out, was not as internal-only as\n> we'd hoped).\n>\n> For \"list\" it's clear how to use \"foreach\" instead, but for \"name\" then\n> AFAICT the \"best\" replacement is to do a:\n>\n> \tgit submodule foreach 'echo $displaypath $name'\n>\n> And pipe that into grep/sed. If that's fast enough would it satisfy your\n> use-case, or would a \"name\" equivalent be handy?\n>\n> I think the best way to prove that would be e.g.:\n>\n> \tgit submodule foreach-format '%{name}' -- \n>\n> Which, due to the \"foreach\" taking N number of arguments isn't easy to\n> add to \"foreach\" without the interface becoming somewhat tortured (we\n> could add a [---pathspec=]...), but \"-- \" with a\n> different subcommand name seems better.\n\nI agree, that adding support for \"-- \" to an existing or new\nsubcommand, would make it unnecessary to bring back a \"name\" subcommand.\n\nWill \"foreach\"/\"foreach-format\" continue to be limited to active\nmodules? Sometimes it would be nice to list all modules, including\nthose that are inactive. As mentioned earlier \"git ls-files -s | grep\n^160000\" is enough to get a list of the module paths, but sometimes we\nwant more information, e.g., \"git submodule list --include-inactive\n--format '$name $is_active submodule.$name.url' -- \".\n\n Jonas\n"},{"id":"466647","messageId":"b5017077-720b-3085-39f0-54dc6b6fcaf6@opensynergy.com","threadId":"58629","inReplyTo":"xmqqwn904sof.fsf@gitster.g","subject":"Re: \"submodule foreach\" much slower than removed \"submodule--helper --list\"","fromName":"Matti Möll","fromEmail":"matti.moell@opensynergy.com","sentAt":"2022-11-07T11:01:40Z","receivedAt":"2022-11-07T11:06:26Z","isPatch":false,"sender":{"key":"matti.moell@opensynergy.com","avatar":null},"body":"On 16.10.22 00:40, Junio C Hamano wrote:\n> \n> If one likes the output from \"submodule--helper list\" so much, I\n> think your \"ls-files\" above should be the closest. There seems to\n> have existed some logic to squash unmerged entries down to a single\n> one, too (git-submodule.sh in Git 2.0.0 era has a module_list shell\n> function that shows what \"helper list\" should be doing), though.\n\nI do actually like that submodule is hoisted out of the scripts but as a \nmatter of fact it seems that the openembedded folks relied on the \n\"submodule--helper list\" call and with later git versions that doesn't \nwork anymore.\n\nhttps://github.com/openembedded/openembedded-core/commit/6d9364e5f3535954f65cbbc694ee7933ac1d664f\n\nAt the end of the day it's kinda their fault to depend on the \nsubmodule--helper but it does hinder adoption of new git versions for \npeople using openembedded.\n\nCheers,\n\n\t\tMatti\n"},{"id":"466782","messageId":"Y2nD9AR8acaGLXDH@nand.local","threadId":"58629","inReplyTo":"b5017077-720b-3085-39f0-54dc6b6fcaf6@opensynergy.com","subject":"Re: \"submodule foreach\" much slower than removed \"submodule--helper --list\"","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2022-11-08T02:50:28Z","receivedAt":"2022-11-08T02:50:50Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Mon, Nov 07, 2022 at 12:01:40PM +0100, Matti Möll wrote:\n> On 16.10.22 00:40, Junio C Hamano wrote:\n> >\n> > If one likes the output from \"submodule--helper list\" so much, I\n> > think your \"ls-files\" above should be the closest. There seems to\n> > have existed some logic to squash unmerged entries down to a single\n> > one, too (git-submodule.sh in Git 2.0.0 era has a module_list shell\n> > function that shows what \"helper list\" should be doing), though.\n>\n> I do actually like that submodule is hoisted out of the scripts but as a\n> matter of fact it seems that the openembedded folks relied on the\n> \"submodule--helper list\" call and with later git versions that doesn't work\n> anymore.\n>\n> https://github.com/openembedded/openembedded-core/commit/6d9364e5f3535954f65cbbc694ee7933ac1d664f\n>\n> At the end of the day it's kinda their fault to depend on the\n> submodule--helper but it does hinder adoption of new git versions for people\n> using openembedded.\n\nYeah, I agree. It's unfortunate, but I think we consider anything with\n'--' in the builtin name to be outside of our compatibility guarantee.\n\nI recall a recent message on the list which where Junio said as much,\nbut I can't seem to find it :-<.\n\nThanks,\nTaylor\n"},{"id":"466787","messageId":"221108.86tu3aru3d.gmgdl@evledraar.gmail.com","threadId":"58629","inReplyTo":"Y2nD9AR8acaGLXDH@nand.local","subject":"Re: \"submodule foreach\" much slower than removed \"submodule--helper --list\"","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-11-08T03:37:55Z","receivedAt":"2022-11-08T03:41:32Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Nov 07 2022, Taylor Blau wrote:\n\n> On Mon, Nov 07, 2022 at 12:01:40PM +0100, Matti Möll wrote:\n>> On 16.10.22 00:40, Junio C Hamano wrote:\n>> >\n>> > If one likes the output from \"submodule--helper list\" so much, I\n>> > think your \"ls-files\" above should be the closest. There seems to\n>> > have existed some logic to squash unmerged entries down to a single\n>> > one, too (git-submodule.sh in Git 2.0.0 era has a module_list shell\n>> > function that shows what \"helper list\" should be doing), though.\n>>\n>> I do actually like that submodule is hoisted out of the scripts but as a\n>> matter of fact it seems that the openembedded folks relied on the\n>> \"submodule--helper list\" call and with later git versions that doesn't work\n>> anymore.\n>>\n>> https://github.com/openembedded/openembedded-core/commit/6d9364e5f3535954f65cbbc694ee7933ac1d664f\n>>\n>> At the end of the day it's kinda their fault to depend on the\n>> submodule--helper but it does hinder adoption of new git versions for people\n>> using openembedded.\n>\n> Yeah, I agree. It's unfortunate, but I think we consider anything with\n> '--' in the builtin name to be outside of our compatibility guarantee.\n>\n> I recall a recent message on the list which where Junio said as much,\n> but I can't seem to find it :-<.\n\nWe've never even documented it, so the uses that have been made of it\nhave been the result of source spelunking. \n\nB.t.w. the openembedded commit above using \"git config\" is not going to\nget the same results as \"git submodule--helper list\", or the equivalent\n\"git submodule foreach\", but perhaps it works well enough for what they\nneed it for...\n"}]}