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@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
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