Re: [PATCH] git-remote: make remote name optional for prune operation

[Junio C Hamano <gitster@pobox.com>]

Julien Danjou <julien@danjou.info> writes:

> We consider that if `git remote prune` is called without a name, we
> actually want to prune all remotes.

I think we try to make an opearation that discards information from many
things at once by mistake, and it feels that this patch goes against it.

In what situation does this new short-cut make things convenient, and how
often does such a situation come up?  The only one I can think of is when
you are interacting with many volatile remotes that create and delete
branches all the time, and when you are trying to repack/pack-ref your
local repository with as much cruft removed, but in such a set-up, next
time you interact with your remotes, you will get their "branch of the
day" in your remote tracking namespace that will disappear shortly, and it
does not sound like it is such a big deal if you did not run "remote
prune" to all of them at once anyway.

Having said all that...

> diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
> index 9e2b4ea..c566061 100644
> --- a/Documentation/git-remote.txt
> +++ b/Documentation/git-remote.txt
> @@ -15,7 +15,7 @@ SYNOPSIS
>  'git remote rm' <name>
>  'git remote set-head' <name> [-a | -d | <branch>]
>  'git remote show' [-n] <name>
> -'git remote prune' [-n | --dry-run] <name>
> +'git remote prune' [-n | --dry-run] [name]
>  'git remote update' [-p | --prune] [group | remote]...

I think you would want to say [<name>] here, but looking at this list, I
wonder if it would be more appropriate to allow "remote group" to be given
to "prune" (and perhaps "show").