Re: [RFC PATCH] push: start warning upcoming default change for push.default

[Jeff King <peff@peff.net>]

On Wed, Mar 14, 2012 at 09:59:04AM +0100, Michael Haggerty wrote:

> > Ending that confusion is one of the best reasons to switch the default,
> > IMHO, but I don't think it argues for "current" versus "upstream", as
> > they both fix it (but Michael's matching-current hybrid would not, so I
> > agree it is less appealing).
> 
> In the case of my proposed matching-current hybrid, the error message
> for the failing push would make it pretty obvious what went wrong and
> how to fix it; something like:
> 
>     $ git push
>     The remote repository "git.example.com:myproject" does not yet
>     contain a branch called "master".  If you would like to create one
>     now, type
> 
>         git push origin master
> 
>     For other alternatives, please see gitworkflows(7).
> 
> This error message would appear *whenever* the matching-current hybrid
> policy caused the push to fail.  Since this problem occurs only if (1)
> the upstream repository is empty and (2) the user hasn't configured a
> more liberal global push.default, and since it is blindingly obvious
> what to do to fix the problem, it doesn't seem especially onerous.

Thanks for the clarification. That does go a long way towards dealing
with the confusion. I think I'd be OK with that, though I am on the
fence about whether just pushing (i.e., "current") would be better or
worse.

> 3. In the branching configurations for which all workflows agree about
>    what "git push" should do, then that is what "git push" should do by
>    default.  When they do not agree, then "git push" should do nothing,
>    give an informative error message, and leave it to the user to
>    decide.
> [...]
> Isn't it obvious?: The fact that we cannot even agree among ourselves
> what "git push" should do in all cases *proves* that we are trying to be
> too ambitious with DWIM.  "git push" must therefore become more
> deferential when the obvious thing to do is unclear, especially given
> that mistakes (due to the very nature of "git push") often have
> embarrassing and publicly visible effects.

I find your approach interesting, but it doesn't deal with one problem:
user perception when git fails to do something out of the box. I am
worried that the rule above means that push will end up defaulting to
nothing. It is one thing to say "there are so many workflows, and they
do not agree, so we should be safe and do nothing"; that makes sense to
an advanced user who thinks about things like different workflows. But
to a brand-new git user who is running "push" in their first session, it
makes git seem very unfriendly.

And that's why I think either "current" or "current-if-matching" as you
describe is a sane default. I don't think it matches with what the
"upstream" people want, and so does not meet your criteria above as a
default behavior. But it does something sensible and not very dangerous
or embarrassing, and it means git will do something that is probably
useful out of the box for a new user.

-Peff