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

Felipe Contreras [off-list ref] writes:

On Mon, Nov 7, 2011 at 11:25 PM, Junio C Hamano [off-list ref] wrote:

quoted

Jeff King [off-list ref] writes:

quoted

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.

On Tue, Nov 8, 2011 at 7:49 PM, Junio C Hamano [off-list ref] wrote:

Felipe Contreras [off-list ref] writes:

quoted

On Mon, Nov 7, 2011 at 11:25 PM, Junio C Hamano [off-list ref] wrote:

quoted

Jeff King [off-list ref] writes:

quoted

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.

Perhaps these 'git remote' commands should be removed in 1.8 then.

-- 
Felipe Contreras