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

[Michael Haggerty <mhagger@alum.mit.edu>]

On 03/12/2012 07:37 PM, Jeff King wrote:
> On Mon, Mar 12, 2012 at 05:37:32PM +0100, Matthieu Moy wrote:
>> * For newbies, the sequence "create an empty repository, clone it,
>>   commit and push" works like a charm with either 'upstream' or
>>   'current'. Today, the first push to an empty repository requires
>>   either saying "git push origin master" or "git push --all", both of
>>   which sound like black magic to the poor user who did not yet learn
>>   what 'origin' is and what a branch is.
> 
> 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.

(One could even create a special-case to allow such a push when the
upstream repository is empty, but I don't think the gain in convenience
is worth the loss of consistency.)

> So far a lot of the discussion has focused on "what is the most sensible
> default for the most number of people". But I wonder if a better
> question is "what is the default that is the least likely to do
> something dangerous and embarrassing". People who use git enough to say
> "wow, I don't like this default for my workflow" are probably at the
> point that they can configure push.default themselves.

I agree entirely.  And here is an algorithm for deciding what the
default should be:

1. Make a list of branch configurations that can be distinguished by
   git, which would be something like all combinations of

   * remote has a branch with the same name as the current branch?
     * no
     * yes, and remote branch could be fast-forwarded to local state
     * yes, but remote branch cannot be fast-forwarded to local state

   * local branch has known upstream branch on remote?
     * no
     * yes, and remote upstream branch could be fast-forwarded to
       the state of the current local branch
     * yes, but remote upstream branch cannot be fast-forwarded to
       the state of the current local branch

2. In each of these situations, decide what "git push" should do in
   each of the common workflows.

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.  If all workflows agree on a safe subset of what "git push"
   should do (for example, "matching" and "current" agree that the
   current branch should be pushed even though they disagree whether
   other branches should be pushed), then it might be OK to carry out
   the safe subset.

The most common workflows, along with the configuration settings that
are recommended for that workflow, should be given standard names and
documented in gitworkflows(7).  The warning message for a failed "git
push" invocations (especially if push.default is unset) should direct
the user to this manpage.


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.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/