git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [BUG?] git submodule update --remote assumes 'origin' remote

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
Mar 1, 2021, 16:38 UTC
Message-ID
<87lfb6kewc.fsf@evledraar.gmail.com>
In-Reply-To
<2d58fe40-9e8c-4653-8170-5411fd3cf6f4@www.fastmail.com>
On Mon, Mar 01 2021, Sean Barag wrote:
Show 40 quoted lines
> I think I've found a bit of an edge case in
> `git submodule update --remote` [1] that got easier to reproduce in
> 2.30+ under certain configurations.
> `git submodule--helper print-default-remote` defaults to 'origin' when
> run in a submodule in a detached HEAD state or on a branch with no
> remote tracking branch [1].  In git < 2.30, the only way for that
> default to be incorrect required a user to manually change remote names
> with something like `git -C ./some-sm remote rename origin foo`.
> `git rev-parse`ing that ref would naturally fail, but at least it's
> because the user took manual steps to break git's assumptions.
>
> Under git 2.30+ with clone.defaultRemoteName set however, submodules are
> created with that remote name instead of 'origin'.  The same behavior
> occurs, but this time without direct user action - only a simple
> `git submodule init && git submodule update --remote` is required.
>
> I'm terribly sorry about that regression - I've only just started
> working on a few projects that use submodules heavily and probably could
> have found this sooner.  I'm happy to fix it, but would *super*
> appreciate a little guidance.  It seems the intention is "use the remote
> that has the url found in the superproject's .submodules entry", that'd
> require `git submodule--helper print-default-remote` to be called from
> the superproject from what I can tell.  I've experimented with
> introducing fallbacks to `remote_for_branch` in `remote.c` [2] as an
> alternative:
>
> 1. use remote tracking branch; or
> 2. if there's only one remote, use that; or
> 3. if config.defaultRemoteName is set, use that; or
> 4. fall back to "origin"
>
> This seems to work (at the very least, no tests fail?), but leaves
> `cd ./some-sm; git remote add foo bar; git remote rename origin baz`
> open to the original behavior.
>
> Something tells me y'all will have a very simple solution that I'm
> missing :)
>
> Again, I'm so sorry for introducing a regression here!
> Sean Barag

Just a quick note, I gather you're talking about de9ed3ef37 (clone: allow configurable default for `-o`/`--origin`, 2020-10-01) which was first released in v2.30.0.

Just noting that in the context of this bug already being in a release, since we're now in the 2.31.0-rc0 period. Meaning likely not a release blocker in the next few weeks.

Previous: Sean BaragNext: Sean Barag
Message 2 of 4 in “[BUG?] git submodule update --remote assumes 'origin' remote”
  1. Sean BaragMar 1, 2021
  2. Ævar Arnfjörð BjarmasonMar 1, 2021
  3. Sean BaragMar 1, 2021
  4. Sean BaragMar 1, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.