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

On 19/03/12 22:59, Junio C Hamano wrote:

So we've identified the following groups:

1. People who can't be harmed by this change (e.g. new users and people
that would only ever use the new default behaviour)

2. People who are harmed by this change, and get information from this
list via some direct or indirect means (e.g. kernel devs or people using
a well-behaved distro)

3. People who are harmed by this change, are impervious to information
from this list, but update at sensible intervals and pay attention to
warning messages (e.g. corporate environments with frequent upgrade cycles)

4. People who are harmed by this change, are impervious to information
from this list, update at long intervals and pay attention to warning
messages (e.g. corporate environments with infrequent upgrade cycles)

5. People who are harmed by this change, upgrade their system
occasionally, but don't want to hear about behaviour changing from what
it has always been (Slackware users ;)

I guess we can agree that group 1 is already well cared for by recent publicity, and group 5 is beyond our ability to handle.

Easy-to-cherry-pick patches are a good solution for group 2 - how about also making a second "default flip" patch available earlier, for people that want to go ahead of the main repo? For example, Debian might want to put this patch in before a feature freeze hits so that their build of git behaves the same as everyone else once they've finished the extensive QA process for the distro.

Warning messages as you've described them are a good solution for group
3.  I think we disagree about the size of this group, but I've only got
anecdotal evidence so what do I know.

People in group 4 aren't served well by any solution that involves some day removing the warning altogether, because there will always be someone that upgrades the day after we remove the warning and says "why wasn't I informed?".

I assume the reason for removing the warning altogether is that some day the signal:noise ratio will just get too bad. Improving the S:N ratio strikes me as useful even ignoring group 4, but anything that increases the amount of time we can warn means that more of them will be informed.

This might have been implicit all along, but one easy way to improve the S:N ratio would be to have the warning message tell people to use `git config --global`. Then people only ever need to see the message once each, no matter how many repos they create.

We could also try to measure the S:N ratio by having a period where the message says "... please e-mail git@vger.kernel.org if you found this message useful, otherwise we'll assume nobody cares and delete it". Then when somebody comes along and asks why they weren't informed, we at least have a good answer.

Finally, as a modification to my previous suggestion, we could `git config push.default <whatever>` when new repos are created and no global/system push.default is found, *instead* of removing the warning altogether at the end of the process. This would mean that everyone in group 3 is informed, as are the vast majority of group 4. The only people that can then be harmed are those that do an exceptionally good job of disguising themselves as new users (e.g. scripts that regularly create throw-away repositories without ever looking at old ones).

	- Andrew