{"thread":{"id":"65867","subject":"Re: Fetching missing submodule refs unnecessarily fatal","startedAt":"2026-06-24T16:15:14Z","lastAt":"2026-06-24T16:15:14Z","messageCount":1,"participants":["Ben Knoble"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"546333","messageId":"BEBEED4A-5677-4B74-9B69-E1614158ECD4@gmail.com","threadId":"65867","inReplyTo":"ajvouniXVAPH8nyZ@mcrowe.com","subject":"Re: Fetching missing submodule refs unnecessarily fatal","fromName":"Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-06-24T16:15:02Z","receivedAt":"2026-06-24T16:15:14Z","isPatch":false,"body":"[re adding list, woops!]\n\n> Le 24 juin 2026 à 10:24, Mike Crowe <mac@mcrowe.com> a écrit :\n> \n> On Wednesday 24 June 2026 at 08:39:39 -0400, Ben Knoble wrote:\n>> \n>>>> Le 23 juin 2026 à 11:04, Mike Crowe <mac@mcrowe.com> a écrit :\n>>> \n>>> When Git fetches in a superproject with --recurse-submodules, it appears to\n>>> try to fetch the corresponding submodule repository commits for every new\n>>> or updated superproject branch. Presumably this is so that everthing is\n>>> ready to switch to one of those branches without further fetching.\n>>> \n>>> Developers may create commits that contain submodules that reference\n>>> commits in the submodule repository, but those commits may not be pushed to\n>>> the submodule's remote repository. When the superproject commits are pushed\n>>> to a personal remote branch anyone else's Git fetch cannot find the\n>>> corresponding submodule commit and fails.\n>> \n>> This is the part that confuses me: if a (public) commit of history refers\n>> to a submodule at a particular commit, and that commit is not available\n>> anywhere, then we won’t be able to properly update submodules when using\n>> that commit. That creates a problem!\n> \n> It does. But only for that user's personal branch. Even though it is\n> public, a personal branch is mostly only for the use of that user and it\n> doesn't matter to anyone but them. (The user is probably working\n> simultaneously on both the superproject and the submodule.)\n> \n>> Why not instead make sure the submodule commit is also available for fetching?\n> \n> This relies on the user realising what they've done. They might even think\n> that they've made the right submodule commit available but forgot that they\n> rebased it before pushing or something changing the commit hash.\n\nYeah, the recurse-submodules option for pushing makes this easier to notice/act on, too. \n\n> From a resilience point of view it shouldn't be possible for someone who\n> can push changes to their own personal branch to perform a \"denial of\n> service\" on anyone else fetching from the repository by making that fetch\n> fail.\n> \n> I hope this makes it clearer.\n\nThat does make some sense: I wouldn’t want to get interrupted by a colleague or collaborator’s bad push of an unrelated branch. \n\n> Thanks.\n> \n> Mike.\n> \n> (Was there a reason that you didn't reply to the list?)\n\nNope, mis-click. "}]}