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

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?