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
