Re: Fetching missing submodule refs unnecessarily fatal

[Ben Knoble <ben.knoble@gmail.com>]

[re adding list, woops!]

> Le 24 juin 2026 à 10:24, Mike Crowe <mac@mcrowe.com> a écrit :
> 
> On Wednesday 24 June 2026 at 08:39:39 -0400, Ben Knoble wrote:
>> 
>>>> Le 23 juin 2026 à 11:04, Mike Crowe <mac@mcrowe.com> 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.