On Thu, Apr 02, 2009 at 06:07:33PM +0200, demerphq wrote: > Er, personally i find that documentation pretty cryptic. And when i > check git config for group, i see this: > > remotes.<group> > The list of remotes which are fetched by "git remote update > <group>". See git-remote(1). Yeah, this should probably say "separated by space" or whatever (I actually don't even know). I would assume it contains the remote name; I can't imagine what other thing it would include. But it wouldn't hurt to make that more explicit. I'm sure a documentation patch would be welcome. > remote.<name>.skipDefaultUpdate > If true, this remote will be skipped by default when updating using > the update subcommand of git-remote(1). > > Neither of which really explain groups, how to define them properly, > (the list is separated by what? and includes the remote name?) or > whether there are implicit groups. I mean, it seems logical that if > you can have user defined groups that there are some built in ones > too, like "all" and "none" or perhaps groups defined by transport > "http" or "git" for instance. I think what is confusing is that there is exactly one implicit group, and it is "the default group", which contains every remote that doesn't have skipDefaultUpdate set. You refer to the "default group" by not mentioning any group. So no, there aren't other implicit groups (AFAIK). You can propose implicit groups, but I think they would have to have a compelling use case over simply creating them manually. To avoid conflict with groups people have already defined, they would only be used if no remotes.$whatever config existed. I think having "git remote update foo" fall back to a group containing only the remote "foo" when "remotes.foo" does not exist makes sense. I'm not sure that "none", "http", or "git" is all that useful in practice (the only thing I can think of for the latter two is that you might use "git" versus "http" depending on restrictive firewall settings). You could give the unnamed "default group" a name (like "all"), but then you risk conflict with existing "remotes.all". And in this case, it is hard to remain backwards compatible: "git remote update" will do something different now in the case that the user has configured remotes.all. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
