# Re: Fetching missing submodule refs unnecessarily fatal 1 messages from 2026-06-24 to 2026-06-24. Participants: Ben Knoble. Thread: https://gitlist.dev/t/65867 ## Ben Knoble, 2026-06-24 16:15 Subject: Re: Fetching missing submodule refs unnecessarily fatal Message-ID: In-Reply-To: ``` [re adding list, woops!] > Le 24 juin 2026 à 10:24, Mike Crowe a écrit : > > On Wednesday 24 June 2026 at 08:39:39 -0400, Ben Knoble wrote: >> >>>> Le 23 juin 2026 à 11:04, Mike Crowe a écrit : >>> >>> When Git fetches in a superproject with --recurse-submodules, it appears to >>> try to fetch the corresponding submodule repository commits for every new >>> or updated superproject branch. Presumably this is so that everthing is >>> ready to switch to one of those branches without further fetching. >>> >>> Developers may create commits that contain submodules that reference >>> commits in the submodule repository, but those commits may not be pushed to >>> the submodule's remote repository. When the superproject commits are pushed >>> to a personal remote branch anyone else's Git fetch cannot find the >>> corresponding submodule commit and fails. >> >> This is the part that confuses me: if a (public) commit of history refers >> to a submodule at a particular commit, and that commit is not available >> anywhere, then we won’t be able to properly update submodules when using >> that commit. That creates a problem! > > It does. But only for that user's personal branch. Even though it is > public, a personal branch is mostly only for the use of that user and it > doesn't matter to anyone but them. (The user is probably working > simultaneously on both the superproject and the submodule.) > >> Why not instead make sure the submodule commit is also available for fetching? > > This relies on the user realising what they've done. They might even think > that they've made the right submodule commit available but forgot that they > rebased it before pushing or something changing the commit hash. Yeah, the recurse-submodules option for pushing makes this easier to notice/act on, too. > From a resilience point of view it shouldn't be possible for someone who > can push changes to their own personal branch to perform a "denial of > service" on anyone else fetching from the repository by making that fetch > fail. > > I hope this makes it clearer. That does make some sense: I wouldn’t want to get interrupted by a colleague or collaborator’s bad push of an unrelated branch. > Thanks. > > Mike. > > (Was there a reason that you didn't reply to the list?) Nope, mis-click. ```