Re: [RFC PATCH] git push: Push nothing if no refspecs are given or configured

If you want to pursue this, you at least need three patches, preferably four:

 (1) Add a configuration option the existing users can use to ask for
     "with nothing else, please continue to default to matching refs".

     Add a logic to tell "nothing is configured, hence we default to
     matching refs" and "the user explicitly told us either via the
     command line, or in the configuration file to use matching refs"
     cases.  Use the logic to issue a *warning* upon the former case that
     tells the users the following, very loudly:

     - "default to push matching" may be changed in a future version of
       git to "default to push nothing";

     - The user can squelch the warning by various ways:

       - If you want to keep the "matching refs" behaviour, do $this...
       - If you want to have $this behaviour, do $that...
       - ...

     Keep the default for the unconfigured case, after issuing the
     warning, to the matching refs.

 (2) Add a deprecation notice to Documentation/RelNotes-1.6.3.txt similar
     to the way denyCurrentBranch was announced in 1.6.2 release notes (I
     need to carry that part forward to the draft release notes to 1.6.3).

     Mention that these two patches are proposed to be applied immediately.

 (3) Flip the default for unconfigured case to "nothing".  Update the
     warning message you wrote in (1) to explain that:

     - The default used to be "matching refs", but it now is "nothing".
       This message is given loudly because a silent change of default 
       is dangerous to users.

     - The user can squelch the warning by doing ... (I expect the
       instructions will stay the same as in (1)).

     Mention that this patch is proposed to be applied in the next major
     update (perhaps 1.7.0).

 (4) Remove the warning but keep the default to "nothing".  Mention that
     this is to be applied long after (3).

I won't comment on code quality other than hinting that you do not want to reinvent has_multiple_bits().