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

[Holger Hellmuth <hellmuth@ira.uka.de>]

On 13.03.2012 14:17, Junio C Hamano wrote:
> that is required to understand it is greater.  Also the current
> implementation of 'upstream' has some weird semantics (or undesigned
> bugs) pointed out by Peff, which would make it even more confusing.

If Peff's "push to same branch in a different remote" is a bug (and IMHO 
it is) it should not count as a reason for what should be the default.

One small point in favor of "current" I haven't seen mentioned: It is 
the smaller/more compatible change from the "matching" behaviour.

The most important point for me in the discussion up till now (because 
it matches my newbie experiences): It doesn't matter that much for new 
users whether "current" or "upstream" is default, because they mostly 
work on master and create branches from local master.

But in that case the typical situation where the default comes into play 
will be when they accidentally are on a branch other than master and try 
to use 'git push'. In that case "current" would push (wrongly) to a 
similar named branch on the remote while upstream would not because the 
local branch would have no upstream configured. Small point in favor of 
"upstream"

The symmetry is what really makes me vote for "upstream". Both 
"upstream" and "current" play to the expectations of new users, 
"upstream" because of the symmetry and "current" because they usually 
expect some connection between branches of the same name in different 
repositories. But only upstream will help those who want to cure git 
push with git pull. And that would be the whole crowd having just a 
whiff of experience with cvs or svn. And if I could take a guess, that 
is the case for the majority of computer science students at a typical 
university (the rest mostly having no experience with version control at 
all)



By the way, the documentation is very confusing in its description what 
git push without parameters does. For example it is not really explained 
in the description or options part, the only explanation is in the 
Examples. There "git push" points to "git push origin" and:
-------------
"git push origin
            Without additional configuration, works like git push origin :.

            The default behavior of this command when no <refspec> is 
given can be configured by setting the push option of the
            remote.
------------

Now the refspec documentation never says anything about what '.' means 
(the only docu about refspecs I could find is in pull-fetch-param.txt 
that is included by git-fetch and git-pull. I thought there was another 
manpage about refspecs but I couldn't find it).
And shouldn't the second sentence above be "... can be configured by 
setting the push.default option of the remote" ?

Is this patchworthy (in that case I'll try to make one) or did I just 
not read at the right places?