Re: [PATCH] Allow --quiet option to git remote, particularly for `git remote update`

[Alex Vandiver <alex@chmrr.net>]

At Sat Dec 05 21:04:14 -0500 2009, Junio C Hamano wrote:
> Alex Vandiver <alex@chmrr.net> writes:
> > ...
> >      "git remote prune [-n | --dry-run] <name>",
> > -    "git remote [-v | --verbose] update [-p | --prune] [group | remote]",
> > +    "git remote [-v | --verbose] [-q | --quiet] update [-p | --prune] [group]",

Hm, I hadn't noticed that I'd changed "[group | remote]" to "[group]".
I think this is due to a mismerge on my part -- apologies.  As another
data point, `git fetch` describes this as "[<repository> | <group>]".

> Three issues to consider:
> 
>  - shouldn't we use the same typography, i.e. <group>?
> 
>  - should we say <name> _if_ we are not going to say <group>|<remote>?
> 
>  - should we keep it as <group>|<remote> to make it clear that only this
>    subcommand allows the group nickname?
> 
> The first two are easy and I expect the answers to be both yes.  The third
> one needs some studying and further thought.
> 
>  - is "remote update" the only one that takes group nickname?

My quick skim of the code says "yes" -- the other commands only deal
with single remotes at a time, and prune is oblivious to groups.

>  - should "remote update" the only one? e.g. does "remote prune" also
>    take group? if not, shouldn't it?

Properly, it "ought" to, though I don't see much utility over `git
remote fetch --prune groupname`.  Probably at the same time, the
parallel pruning codepaths in builtin-fetch.c:prune_refs() and
builtin-remote.c:prune_remote() should be unified.
 - Alex
-- 
Networking -- only one letter away from not working