Re: bug: submodule update fails to fetch

From: Taylor Blau <me@ttaylorr.com>
Date: Jun 22, 2023, 13:07 UTC
Message-ID: <ZJRHlJvE4BMue1/Z@nand.local>
In-Reply-To: <ZJQr0_aC-NlLXDgj@pweza>

On Thu, Jun 22, 2023 at 01:09:07PM +0200, Sergei Golubchik wrote:

Show 26 quoted lines

> Hi,
>
> Sometimes (my local repository has lots of branches) after switching
> branches
>
>   git submodule update --init --recursive
>
> fails with something like
>
>   fatal: transport 'file' not allowed
>   fatal: Fetched in submodule path 'wsrep-lib', but it did not contain e238c0d240c2557229b0523a4a032f3cf8b41639. Direct fetching of that commit failed.
>
> the submodule transport is not 'file' (it's https) and the direct
> fetching of the commit actually works:
>
>   cd wsrep-lib
>   git fetch origin e238c0d240c2557229b0523a4a032f3cf8b41639
>   git checkout e238c0d240c2557229b0523a4a032f3cf8b41639
>   cd ..
>
> after that
>
>   git submodule update --init --recursive
>
> succeeds. This happens deterministically, but depends on the old and new
> commits in the last checkout. As a workaround we've had to change our CI to do

It makes sense that after manually fetching the desired tip that the submodule update goes through OK, because there is nothing to do (the checked-out state matches what's in .gitmodules), so we don't have to use any transport mechanism.

I recently changed the submodule update rules to disallow file-based submodules when not directly executed by the user. See a1d4f67c12 (transport: make `protocol.file.allow` be "user" by default, 2022-07-29) for more of the details there.

So in the short term, you should able to work around what you're seeing by setting `protocol.file.allow` to "always" with something like

    $ git config --global protocol.file.allow always

But in the short-term, I am curious why we are complaining about needing to use the file transport when you claim that the submodule actually needs the HTTPS transport.

Are you able to share a copy of your repository, and/or its .gitmodules file, and your repository-local .gitconfig, as well? Do you have some `url.<base>.insteadOf` value configured elsewhere that would be rewriting those paths for you?

Thanks, Taylor