Re: Please discuss: what "git push" should do when you do not say what to push?

At $dayjob, our setup instructions for Git do say that everyone setting up a new machine shall run "git config --global push.default tracking". This is what suits our workflow where people work on a topic branch, which they will push to and pull from our central repository (each topic branch is owned by a team of one or more developers). By using "tracking", they can just do a

   git push

and not have to worry about other half-finished or local changes "pollute" the One True Central Repository<tm>. We have found that this configuration makes it easier to explain the workflow, especially since it more or less does make "push" the opposite of "pull" (both of them just updating one "real" branch on either side).

We also have cases where we work on different repositories, with different codebases; we have an upstream codebase that is merged into one or more downstream codebases, and sometimes we have branches that are used with more than one codebase (pull branch A from upstream repo, merge with downstream repo and work with it there). Or we work on cross-codebase maintainence (transplant fix on branch A from codebase B to codebase C). We have installed hooks on our repositories that try to make sure history does not get pushed to the wrong repository -- as could sometimes happen if you had a branch checked out locally from the another codebase and forgot to configure your push.default.

I have also personally found that this is the setting that I do feel most comfortable with in more or less every other context where I work with Git, so I do think this would be a fairly useful default value.

I know the policy in Git is to not allow the remote repository dictate anything about the configuration in the local repository, but as an alternative to changing the "push.default" value, perhaps we should allow setting some configuration option on the remote repository that blocks it from being the target of a "push.default = matching" push?