On Tue, Nov 8, 2011 at 7:49 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > >> On Mon, Nov 7, 2011 at 11:25 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Jeff King <peff@xxxxxxxx> 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. Perhaps these 'git remote' commands should be removed in 1.8 then. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html