Re: [PATCH] git remote update: New option --prune (-p)

[Jeff King <peff@peff.net>]

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