{"thread":{"id":"55239","subject":"[BUG?] git submodule update --remote assumes 'origin' remote","startedAt":"2021-03-01T15:48:01Z","lastAt":"2021-03-01T17:30:47Z","messageCount":4,"participants":["Sean Barag","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"418039","messageId":"2d58fe40-9e8c-4653-8170-5411fd3cf6f4@www.fastmail.com","threadId":"55239","inReplyTo":null,"subject":"[BUG?] git submodule update --remote assumes 'origin' remote","fromName":"Sean Barag","fromEmail":"sean@barag.org","sentAt":"2021-03-01T15:46:29Z","receivedAt":"2021-03-01T15:48:01Z","isPatch":false,"sender":{"key":"sean@barag.org","avatar":"https://avatars.githubusercontent.com/u/665775?v=4"},"body":"I think I've found a bit of an edge case in\n`git submodule update --remote` [1] that got easier to reproduce in\n2.30+ under certain configurations.\n`git submodule--helper print-default-remote` defaults to 'origin' when\nrun in a submodule in a detached HEAD state or on a branch with no\nremote tracking branch [1].  In git < 2.30, the only way for that\ndefault to be incorrect required a user to manually change remote names\nwith something like `git -C ./some-sm remote rename origin foo`.\n`git rev-parse`ing that ref would naturally fail, but at least it's\nbecause the user took manual steps to break git's assumptions.\n\nUnder git 2.30+ with clone.defaultRemoteName set however, submodules are\ncreated with that remote name instead of 'origin'.  The same behavior\noccurs, but this time without direct user action - only a simple\n`git submodule init && git submodule update --remote` is required.\n\nI'm terribly sorry about that regression - I've only just started\nworking on a few projects that use submodules heavily and probably could\nhave found this sooner.  I'm happy to fix it, but would *super*\nappreciate a little guidance.  It seems the intention is \"use the remote\nthat has the url found in the superproject's .submodules entry\", that'd\nrequire `git submodule--helper print-default-remote` to be called from\nthe superproject from what I can tell.  I've experimented with\nintroducing fallbacks to `remote_for_branch` in `remote.c` [2] as an\nalternative:\n\n1. use remote tracking branch; or\n2. if there's only one remote, use that; or\n3. if config.defaultRemoteName is set, use that; or\n4. fall back to \"origin\"\n\nThis seems to work (at the very least, no tests fail?), but leaves\n`cd ./some-sm; git remote add foo bar; git remote rename origin baz`\nopen to the original behavior.\n\nSomething tells me y'all will have a very simple solution that I'm\nmissing :)\n\nAgain, I'm so sorry for introducing a regression here!\nSean Barag\n\n[1] https://github.com/git/git/blob/225365fb5195e804274ab569ac3cc4919451dc7f/git-submodule.sh#L571-L584\n[2] https://github.com/git/git/blob/225365fb5195e804274ab569ac3cc4919451dc7f/remote.c#L477-L487\n"},{"id":"418040","messageId":"87lfb6kewc.fsf@evledraar.gmail.com","threadId":"55239","inReplyTo":"2d58fe40-9e8c-4653-8170-5411fd3cf6f4@www.fastmail.com","subject":"Re: [BUG?] git submodule update --remote assumes 'origin' remote","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-03-01T16:38:43Z","receivedAt":"2021-03-01T16:42:44Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Mon, Mar 01 2021, Sean Barag wrote:\n\n> I think I've found a bit of an edge case in\n> `git submodule update --remote` [1] that got easier to reproduce in\n> 2.30+ under certain configurations.\n> `git submodule--helper print-default-remote` defaults to 'origin' when\n> run in a submodule in a detached HEAD state or on a branch with no\n> remote tracking branch [1].  In git < 2.30, the only way for that\n> default to be incorrect required a user to manually change remote names\n> with something like `git -C ./some-sm remote rename origin foo`.\n> `git rev-parse`ing that ref would naturally fail, but at least it's\n> because the user took manual steps to break git's assumptions.\n>\n> Under git 2.30+ with clone.defaultRemoteName set however, submodules are\n> created with that remote name instead of 'origin'.  The same behavior\n> occurs, but this time without direct user action - only a simple\n> `git submodule init && git submodule update --remote` is required.\n>\n> I'm terribly sorry about that regression - I've only just started\n> working on a few projects that use submodules heavily and probably could\n> have found this sooner.  I'm happy to fix it, but would *super*\n> appreciate a little guidance.  It seems the intention is \"use the remote\n> that has the url found in the superproject's .submodules entry\", that'd\n> require `git submodule--helper print-default-remote` to be called from\n> the superproject from what I can tell.  I've experimented with\n> introducing fallbacks to `remote_for_branch` in `remote.c` [2] as an\n> alternative:\n>\n> 1. use remote tracking branch; or\n> 2. if there's only one remote, use that; or\n> 3. if config.defaultRemoteName is set, use that; or\n> 4. fall back to \"origin\"\n>\n> This seems to work (at the very least, no tests fail?), but leaves\n> `cd ./some-sm; git remote add foo bar; git remote rename origin baz`\n> open to the original behavior.\n>\n> Something tells me y'all will have a very simple solution that I'm\n> missing :)\n>\n> Again, I'm so sorry for introducing a regression here!\n> Sean Barag\n\nJust a quick note, I gather you're talking about de9ed3ef37 (clone:\nallow configurable default for `-o`/`--origin`, 2020-10-01) which was\nfirst released in v2.30.0.\n\nJust noting that in the context of this bug already being in a release,\nsince we're now in the 2.31.0-rc0 period. Meaning likely not a release\nblocker in the next few weeks.\n"},{"id":"418045","messageId":"58d3b7ba-b65d-432f-872d-adea7fad1317@www.fastmail.com","threadId":"55239","inReplyTo":"2d58fe40-9e8c-4653-8170-5411fd3cf6f4@www.fastmail.com","subject":"Re: [BUG?] git submodule update --remote assumes 'origin' remote","fromName":"Sean Barag","fromEmail":"sean@barag.org","sentAt":"2021-03-01T17:17:40Z","receivedAt":"2021-03-01T17:22:20Z","isPatch":false,"sender":{"key":"sean@barag.org","avatar":"https://avatars.githubusercontent.com/u/665775?v=4"},"body":"On Mon, Mar 01 2021, Sean Barag wrote:\n\n> I've experimented with\n> introducing fallbacks to `remote_for_branch` in `remote.c` [2] as an\n> alternative:\n> \n> 1. use remote tracking branch; or\n> 2. if there's only one remote, use that; or\n> 3. if config.defaultRemoteName is set, use that; or\n> 4. fall back to \"origin\"\n> \n> This seems to work (at the very least, no tests fail?), but leaves\n> `cd ./some-sm; git remote add foo bar; git remote rename origin baz`\n> open to the original behavior.\n\nI forgot to mention that this approach requires `get_default_remote` in\n`submodule--helper.c` to use the name of the remote returned by\n`remote_get(NULL)`.  That was probably obvious to regular mailing list\nreaders :D\n"},{"id":"418048","messageId":"89889645-d7c4-437e-a072-0ff543fe437c@www.fastmail.com","threadId":"55239","inReplyTo":"87lfb6kewc.fsf@evledraar.gmail.com","subject":"Re: [BUG?] git submodule update --remote assumes 'origin' remote","fromName":"Sean Barag","fromEmail":"sean@barag.org","sentAt":"2021-03-01T17:13:31Z","receivedAt":"2021-03-01T17:30:47Z","isPatch":false,"sender":{"key":"sean@barag.org","avatar":"https://avatars.githubusercontent.com/u/665775?v=4"},"body":"On Mon, Mar 1, 2021, at 8:38 AM, Ævar Arnfjörð Bjarmason wrote:\n> Just a quick note, I gather you're talking about de9ed3ef37 (clone:\n> allow configurable default for `-o`/`--origin`, 2020-10-01) which was\n> first released in v2.30.0.\n\nYes, that's exactly the commit.  I knew I forgot to include something.\n\n> Just noting that in the context of this bug already being in a\n> release, since we're now in the 2.310-rc0 period. Meaning likely not\n> a release blocker in the next few weeks.\n\nThat makes sense - thanks for clarifying!\n"}]}