git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Glen Choo <chooglen@google.com>
To: Jacob Keller <jacob.keller@gmail.com>,
	Git mailing list <git@vger.kernel.org>
Cc: Emily Shaffer <emilyshaffer@google.com>,
	Philippe Blain <levraiphilippeblain@gmail.com>
Subject: Re: issue with submodules using origin remote unexpectadly
Date: Tue, 04 Oct 2022 11:12:41 -0700	[thread overview]
Message-ID: <kl6lzgeblap2.fsf@chooglen-macbookpro.roam.corp.google.com> (raw)
In-Reply-To: <CA+P7+xrnAXceHJbBYV8Z9Ay9xbkzpiX3P0wXLwN7jfnifW2OBQ@mail.gmail.com>

Hi Jacob! Thanks for the report!

I think we'd need a bit more info, specifically:

- How did you rename the remote?
- What command is doing the submodule fetch?

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

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...

>
> 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?

> 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.

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`
- origin

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.

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.
- If the superproject does not have a branch checked out, it uses
  "origin".

>
> Thanks,
> Jake

  reply	other threads:[~2022-10-04 18:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-04 17:43 issue with submodules using origin remote unexpectadly Jacob Keller
2022-10-04 18:12 ` Glen Choo [this message]
2022-10-11 21:15   ` Jacob Keller
2022-10-11 22:20     ` Glen Choo
2022-10-12  0:13       ` Jacob Keller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=kl6lzgeblap2.fsf@chooglen-macbookpro.roam.corp.google.com \
    --to=chooglen@google.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=jacob.keller@gmail.com \
    --cc=levraiphilippeblain@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).