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

remotes group with one member

From
RVRasmus Villemoes <rasmus.villemoes@prevas.dk>
Date
Jan 31, 2022, 14:08 UTC
Message-ID
<b5d27968-fd45-a58e-3619-feadc6a4cc5e@prevas.dk>
Hi,

I was trying to make use of defining a remotes.upstreams group, along with setting up suitable remote.<bla>.fetch variables for each, in order to make sure our local clones of various repositories are kept in sync with various upstream sources - e.g. for the linux kernel, we're pulling from both Linus', -stable and the -rt trees. For other projects, we only have one upstream, but I wanted to keep the logic in the cron job simple so I could do 'git fetch upstreams' in each of them. When there are actually several remotes in the 'upstreams' group, this works fine. But when there's only one (say, origin), it fails with

$ git fetch upstreams fatal: 'upstreams' does not appear to be a git repository fatal: Could not read from remote repository.

If I put the silly value "origin origin" in remotes.upstreams, it works as expected.

Digging into fetch.c, I can see where this behaviour comes from
	} else if (multiple) {
		/* All arguments are assumed to be remotes or groups */
		for (i = 0; i < argc; i++)
			if (!add_remote_or_group(argv[i], &list))
				die(_("no such remote or remote group: %s"),
				    argv[i]);
	} else {
		/* Single remote or group */
		(void) add_remote_or_group(argv[0], &list);
		if (list.nr > 1) {
			/* More than one remote */
			if (argc > 1)
				die(_("fetching a group and specifying refspecs does not make sense"));
		} else {
			/* Zero or one remotes */
			remote = remote_get(argv[0]);
			prune_tags_ok = (argc == 1);
			argc--;
			argv++;
		}
	}

That is, when add_remote_or_group() has resolved the group to just one element in list, we redo the lookup with a remote_get(), essentially forgetting the translation from the group name "upstreams" to the singleton "origin".

This feels like a bug to me, at least a UX one. Looking at this code, I also saw that I could probably work around it if I say "git fetch --multiple upstreams" (and that does work as expected), but it's somewhat counterintuitive to have to specify --multiple to get a singleton group to work.

Rasmus
Message 1 of 1 in “remotes group with one member”
  1. Rasmus VillemoesJan 31, 2022

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.