archive mirror
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <>
To: Sean Barag <>
Subject: Re: [BUG?] git submodule update --remote assumes 'origin' remote
Date: Mon, 01 Mar 2021 17:38:43 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Mar 01 2021, Sean Barag wrote:

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

  reply	other threads:[~2021-03-01 16:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-01 15:46 [BUG?] git submodule update --remote assumes 'origin' remote Sean Barag
2021-03-01 16:38 ` Ævar Arnfjörð Bjarmason [this message]
2021-03-01 17:13   ` Sean Barag
2021-03-01 17:17 ` Sean Barag

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:

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

  git send-email \ \ \ \ \

* 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.
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 NNTP newsgroup(s).