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.
