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().
--
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
