Re: [PATCH] Allow --quiet option to git remote, particularly for `git remote update`
- From
Alex Vandiver <alex@chmrr.net>
- Date
- Dec 7, 2009, 07:23 UTC
- Message-ID
- <1260169742-sup-9991@utwig>
- In-Reply-To
- <7vd42soo2p.fsf@alter.siamese.dyndns.org>
At Sat Dec 05 21:04:14 -0500 2009, Junio C Hamano wrote:
Show 5 quoted lines
> 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>]".
Show 13 quoted lines
> 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