Re: issue with submodules using origin remote unexpectadly

From: Jacob Keller <jacob.keller@gmail.com>
Date: Oct 11, 2022, 21:15 UTC
Message-ID: <CA+P7+xq3NGGTq2U2Di9ZTBO3buqeEMb2smC=v78V9Subt2cDMw@mail.gmail.com>
In-Reply-To: <kl6lzgeblap2.fsf@chooglen-macbookpro.roam.corp.google.com>

On Tue, Oct 4, 2022 at 11:12 AM Glen Choo <chooglen@google.com> wrote:

>
> Hi Jacob! Thanks for the report!
>

Thanks for responding!

Show 5 quoted lines

> I think we'd need a bit more info, specifically:
>
> - How did you rename the remote?
> - What command is doing the submodule fetch?
>

I am doing a git pull --rebase in the superproject, and I renamed the remote in the submodule using git remote rename.

> Or, if you could include a reproduction script, that would be really
> helpful :)
>

I'm not sure how to do this, because it is only an intermittent failure. I suspect it has to do with when the submodule actually needs to update.

Perhaps I can come up with something though. If I can, I'll send it as a new test.

Show 12 quoted lines

> Jacob Keller <jacob.keller@gmail.com> writes:
>
> > Hi,
> >
> > I've been running into an issue with submodules trying to fetch using
> > "origin" even though the submodule does not have a remote by that
> > name. (I recently switched the submodule remote name)
>
> How did you rename the remote? e.g. did you run `git remote rename`, or
> did you rename it manually? I'll come back to why this might be
> important...
>

I renamed it using git remote rename.

Show 23 quoted lines

> >
> > remote: Enumerating objects: 210, done.
> > remote: Counting objects: 100% (207/207), done.
> > remote: Compressing objects: 100% (54/54), done.
> > remote: Total 210 (delta 123), reused 197 (delta 119), pack-reused 3
> > Receiving objects: 100% (210/210), 107.20 KiB | 4.29 MiB/s, done.
> > Resolving deltas: 100% (123/123), completed with 48 local objects.
> > From <redacted>
> > ...
> > Fetching submodule submodule
> > From <redacted>
> >    85e0da7533d9..80cc886f1187  <redacted>
> > Fetching submodule submodule2
> > fatal: 'origin' does not appear to be a git repository
> > fatal: Could not read from remote repository.
> >
> > Please make sure you have the correct access rights
> > and the repository exists.
> > Errors during submodule fetch:
> >         submodule2
>
> I assume this is `git fetch` running in the superproject?
>

Its git pull --rebase, but I suppose as part of this it will run something equivalent to git fetch?

Show 11 quoted lines

> > I thought at first there might be some configuration value in the
> > parent that is selecting origin, but I can 't find one. I also thought
> > maybe its some sort of defaulting to origin but I looked through
> > submodule code and didn't find one.
> >
> > Is it just that submodule code is not resilient against changing the
> > default remote name away from origin?
>
> Yes, in a sense, though I'm not sure if this is the source of your
> problems.
>

Hmm.

Show 8 quoted lines

> When fetching with `git fetch`, submodules are fetched without
> specifying the remote name, which means Git guesses which remote you
> want to fetch from, which is documented at
> https://git-scm.com/docs/git-fetch. I believe (I haven't reread this
> very closely) this is, in order:
>
> - The remote of your branch, i.e. the value of the config value
>   `branch.<name>.remote`

So basically if its checked out to a branch it will fetch from the remote of that branch, but...

> - origin
>

It defaults to origin, so if you have the usual "checked out as a detached head" style of submodule, it can't find the remote branch.

> This is why `git remote rename` matters, because `git remote rename`
> will also rename `branch.<name>.remote`. If you have a branch checked
> out in your submodule, you might want to double-check your .git/config.
>

I do not have a branch checked out, I have it checked out as detached head, as is the usual style for "git submodule update" would do.

Show 6 quoted lines

> But... I'll mention another wrinkle for completeness' sake (though I
> don't think it applies to you). If you fetch using `git submodule
> update`, the submodule is fetched using a _named_ remote, specifically:
>
> - If the superproject has a branch checked out, it uses the name of the
>   superproject branch's remote.

Right, so that explains why I can re-run git submodule update after a git pull --rebase and it works.

In theory wouldn't it make more sense to use the remote based on the URL of the .gitmodules file?

> - If the superproject does not have a branch checked out, it uses
>   "origin".
>

I suppose one option would be to make this configurable. I started using "upstream" as the default remote name for most of my repositories when I began working with forks a lot more.

> >
> > Thanks,
> > Jake