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?
--
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