Re: Fetching missing submodule refs unnecessarily fatal
1 messages between Jun 24, 2026 and Jun 24, 2026, from Ben Knoble.
Plain Markdown or JSON for tools and agents.
Show 32 quoted lines
> 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.
Show 6 quoted lines
> 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.
Show 5 quoted lines
> Thanks.
>
> Mike.
>
> (Was there a reason that you didn't reply to the list?)