{"thread":{"id":"57341","subject":"remotes group with one member","startedAt":"2022-01-31T14:08:06Z","lastAt":"2022-01-31T14:08:06Z","messageCount":1,"participants":["Rasmus Villemoes"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"447332","messageId":"b5d27968-fd45-a58e-3619-feadc6a4cc5e@prevas.dk","threadId":"57341","inReplyTo":null,"subject":"remotes group with one member","fromName":"Rasmus Villemoes","fromEmail":"rasmus.villemoes@prevas.dk","sentAt":"2022-01-31T14:08:00Z","receivedAt":"2022-01-31T14:08:06Z","isPatch":false,"sender":{"key":"rasmus.villemoes@prevas.dk","avatar":null},"body":"Hi,\n\nI was trying to make use of defining a remotes.upstreams group, along\nwith setting up suitable remote.<bla>.fetch variables for each, in order\nto make sure our local clones of various repositories are kept in sync\nwith various upstream sources - e.g. for the linux kernel, we're pulling\nfrom both Linus', -stable and the -rt trees. For other projects, we only\nhave one upstream, but I wanted to keep the logic in the cron job simple\nso I could do 'git fetch upstreams' in each of them. When there are\nactually several remotes in the 'upstreams' group, this works fine. But\nwhen there's only one (say, origin), it fails with\n\n$ git fetch upstreams\nfatal: 'upstreams' does not appear to be a git repository\nfatal: Could not read from remote repository.\n\nIf I put the silly value \"origin origin\" in remotes.upstreams, it works\nas expected.\n\nDigging into fetch.c, I can see where this behaviour comes from\n\n\t} else if (multiple) {\n\t\t/* All arguments are assumed to be remotes or groups */\n\t\tfor (i = 0; i < argc; i++)\n\t\t\tif (!add_remote_or_group(argv[i], &list))\n\t\t\t\tdie(_(\"no such remote or remote group: %s\"),\n\t\t\t\t    argv[i]);\n\t} else {\n\t\t/* Single remote or group */\n\t\t(void) add_remote_or_group(argv[0], &list);\n\t\tif (list.nr > 1) {\n\t\t\t/* More than one remote */\n\t\t\tif (argc > 1)\n\t\t\t\tdie(_(\"fetching a group and specifying refspecs does not make sense\"));\n\t\t} else {\n\t\t\t/* Zero or one remotes */\n\t\t\tremote = remote_get(argv[0]);\n\t\t\tprune_tags_ok = (argc == 1);\n\t\t\targc--;\n\t\t\targv++;\n\t\t}\n\t}\n\nThat is, when add_remote_or_group() has resolved the group to just one\nelement in list, we redo the lookup with a remote_get(), essentially\nforgetting the translation from the group name \"upstreams\" to the\nsingleton \"origin\".\n\nThis feels like a bug to me, at least a UX one. Looking at this code, I\nalso saw that I could probably work around it if I say \"git fetch\n--multiple upstreams\" (and that does work as expected), but it's\nsomewhat counterintuitive to have to specify --multiple to get a\nsingleton group to work.\n\nRasmus\n"}]}