git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Finn Arne Gangstad <finnag@pvv.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Julien Danjou <julien@danjou.info>, git@vger.kernel.org
Subject: Re: [PATCH] git-remote: make remote name optional for prune operation
Date: Wed, 6 May 2009 19:55:00 +0200	[thread overview]
Message-ID: <20090506175500.GA19976@pvv.org> (raw)
In-Reply-To: <7vab5qw3nr.fsf@alter.siamese.dyndns.org>

On Wed, May 06, 2009 at 10:18:48AM -0700, Junio C Hamano wrote:
> 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").

I also think that if we want to change prune, we should change it to
interpret its parameters identically to update. This means that no
argument will not expand to "all remotes", but rather to the possibly
configured "default" group.

In other words: I think "git remote update -p" and "git remote prune"
should prune the same remotes (both with and without additional arguments).

- Finn Arne

      parent reply	other threads:[~2009-05-06 17:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-06 14:37 [PATCH] git-remote: make remote name optional for prune operation Julien Danjou
2009-05-06 14:49 ` Francis Galiegue
2009-05-06 15:32   ` Julien Danjou
2009-05-06 15:46     ` Jacob Helwig
2009-05-06 16:15       ` Michael J Gruber
2009-05-06 16:58         ` Julien Danjou
2009-05-06 17:18 ` Junio C Hamano
2009-05-06 17:54   ` Junio C Hamano
2009-05-06 17:55   ` Finn Arne Gangstad [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090506175500.GA19976@pvv.org \
    --to=finnag@pvv.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=julien@danjou.info \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).