[RFD] what should "git push remote.host:path" do?

[Junio C Hamano <junkio@cox.net>]

The underlying "git send-pack remote.host:path" pushes all the
matching refs that both local and remote has, and "git push"
blindly inherits this property.

This is bad.  A typical cloned repository (e.g. a subsystem
maintainer repository cloned from Linus repository) has at least
two branches, "master" to keep the subsystem and "origin" that
records tip of Linus "master" when the repository was cloned.
If this is the public repository, then subsystem developers
would clone from this one, and then cloned ones have "master"
and "origin".  When developers use this public subsystem
repository as a shared repository, "git push subsys:path" would
try to push the matching refs, "master" and "origin".

One workaround is to delete "origin" branch from the public
repository, because having "origin" there is meaningless.
Nobody is supposed to pull directly into it from Linus after
cloning; rather, changes in upstream would trickle in by a
developer who cloned from this subsystem repository and then
pulled from Linus into his repository and then pushed his merge
result into this public repository.

Nevertheless, exposing the default behaviour of "git send-pack"
to "git push" was probably a mistake.  I'd propose to require at
least one refspec to be specified, either on the command line or
via $GIT_DIR/remotes mechanism.  So my answer to the "Subject: "
line question is "Barf".

Unlike pull that can happen pretty much promiscuously, people
will push into the same set of a limited number of remote
repositories repeatedly over the life of the project, so it is
reasonable to assume they would want to keep a $GIT_DIR/remotes/
entry for those repositories to save typing.  Then always
requiring one or more refspecs for push is not too much to ask
for.

Opinions?

BTW, Nick, what does http-push do with "git push http://foo"
without refspecs?