From: Junio C Hamano <gitster@pobox.com>
Date: Sat, 24 Oct 2009 06:30:16 GMT
Subject: Re: [RFC] pull/fetch rename
Message-ID: <7v4opp9udj.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20091021074522.GA13531@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

> On Wed, Oct 21, 2009 at 12:22:35AM -0700, Junio C Hamano wrote:
>
>> It is not even a typesaver.  "git fetch" updates from the default remote,
>> so does "git remote update".  Personally I think the people who invented
>> "git remote update" were misguided, and that is why I say it was a failed
>> UI experiment that failed, but that is hindsight talking [*1*].
>
> Declaring it a failure depends on what you consider the goal of "git
> remote update" to be. I find it very useful as a shorthand for "fetch
> from _all_ remotes"[1]. Which does save typing over
>
>   $ for i in `git remote`; do git fetch $i; done

You've since read my footnote about "git fetch <group>", so I do not think
this part is controversial anymore.

> And of course, there is "git remote" again, saving us a few keystrokes
> over:
>
>   $ git config --get-regexp 'remote..*.url' | cut -d. -f2

And as you may have already realized by now, I was saying two things.

 (1) "git remote" in general is a good management interface for remote
     nicknames and attributes attached to them, in the similar spirit as
     "git config" is a good management interface for the underlying
     configuration files.

 (2) "git remote update" is a misguided UI expariment that failed.

So there is no disagreement between us on the "and of course" part,
either.