Re: [RFC/PATCH] remote: add new sync command

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 8, 2011, 17:49 UTC
Message-ID: <7vvcquy05c.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAMP44s0vsQ5sfx8arrRDo+-g9Zff_MmCz5t+yghwCMx_pL4Xzg@mail.gmail.com>

Felipe Contreras <felipe.contreras@gmail.com> writes:

Show 17 quoted lines

> On Mon, Nov 7, 2011 at 11:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jeff King <peff@peff.net> writes:
>>
>>> That makes sense. But I think it fits in with git's current UI to do
>>> this via a combination of push options and refspecs. Even if we want to
>>> wrap it in some "git remote" command for convenience, I think what
>>> you're asking should be implemented as part of "git push".
>>
>> Yeah, I think it makes sense to give --prune to "push" just like "fetch"
>> already has. These two are the primary (and in the ideal world, only)
>> operations that talk to the outside world. "remote add -f" might have been
>> a tempting "convenience" feature, but I personally think it probably was a
>> mistake for the exact reason that letting anything but "push" and "fetch"
>> talk to the outside world just invites more confusion. There does not have
>> to be 47 different ways to do the same thing.
>
> What about 'git remote update'?

If you asked, I would have to say that is probably a worse mistake in the hindsight. I am guessing that back them "remote" command might have been a tool meant only for the read-only customers and the verb "update" may have made sense as "update me from the upstream", but these days "remote" also helps the aspect of pushing things out (e.g. "set-url --push"), so "update" that does not specify the direction is totally an inappropriate verb.

You _could_ argue that adding subcommands and options related to pushing to "git remote" was a mistake. I don't care too much which side you would choose to blame, but taken as the whole, in the current set of options, subcommands and what "git remote" command does, "update" is a complete misnomer.