On Mon, Mar 12, 2012 at 05:37:32PM +0100, Matthieu Moy wrote:
> I do find it reasonable, but I think 'upstream' has several advantages
> over it.
>
> * 'upstream' makes "git push" and "git pull" symmetrical. While there
> are workflows where it is usefull to have "push" and "pull" point to
> different branches, I think it is far more intuitive to have this
> symmetry by default.
This is one of the things I really hate about 'upstream'. If you share a
central repo with other people, it makes sense. You push and pull from
the same place. But in the classic kernel-style workflow, you'd pull
from an upstream, and then publish your work elsewhere. And I think it's
not just kernel people who use this asymmetric workflow. On something
like GitHub, you get your own fork repo on the site as a publishing
point. But you also want to keep pulling and basing your work on what
the main project is doing. You can't just pull from your fork, since it
never gets updates from the main project; you pull them into your local
repo, and then push them up to your fork.
So in a very reasonable common newbie workflow, "upstream" will not at
all do what you want, because it will go to the wrong repo[1]
That being said, "current" will _also_ go to the wrong repo, because
push fundamentally respects "branch.*.remote". Which is definitely not
what you want in the asymmetric case. This is not a push.default issue,
but I think it is somewhat related, and maybe worth discussing along
with the topic of asymmetry. Am I the only one who finds this behavior
annoying? I've mostly trained my fingers to type "git push
<my-publish-repo>", but I do occasionally forget. Do other people with
asymmetric workflows find this annoying? Do they not care? Or are many
fewer people doing asymmetric things than I think?
While I'm ranting, there's another weirdness I noticed. If I have
push.default set to upstream, and config like this:
[branch "foo"]
remote = origin
merge = refs/heads/master
then typing "git push" will go to foo's master branch. But if I type
"git push other-remote", then it will go to other-remote's master
branch. Which makes no sense to me. The upstream is foo's master, and
now we are making guesses about how the names on each side are the same.
Is this an intentional behavior?
[1] One saving grace of going to the wrong repo is that you usually
don't have permissions to push to that repo, so you get a harmless
error message.
> * 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).
> * 'upstream' makes it easy to create a local topic branch, and let
> 'push' send it to the master branch (i.e. have local 'topic-branch'
> pull and push to 'origin/master'). In general, 'upstream' allows
> workflows where you push to branches with either a different name or
> with the same name (by setting the upstream appropriately), but the
> opposite is not true.
Actually, this is the thing that scares me the most about "upstream" as
a default, because in this case, you are implicitly performing the
equivalent of a fast-forward merge. So that's handy if you are a new
user who wants to publish your work back to the master branch. But that
has two problems:
1. If you are a new user who does like the implicit merge, you may
find it convenient not to have to learn about "git checkout; git
merge topic ; git push remote master". But it only helps you
_sometimes_. If master has had other work built on it, your push
will fail, and you will have to do the merge yourself. So it is
only helping you by omitting a step some of the time, and you still
have to learn why the step is sometimes necessary and sometimes
not.
Yes, experienced users do not have this learning problem. But
remember we are talking about a default targeted at new users, and
trying to reduce their confusion. People who know and like what
"upstream" does can configure it themselves.
2. If you are a new user who _doesn't_ want to do the merge, but
instead wants to publish your work-in-progress topic, then the
implicit merge-back-to-master behavior is wrong and dangerous.
You are publishing work that probably violates the general rules
for what goes on master.
Or perhaps somebody else has built on top of master, and your push
fails. If you're an astute reader, you will see that the failing
push tried to go to master. But if you're not, you may retry with
"-f", which is quite dangerous, as now you are not just
accidentally publishing a work-in-progress, but you are
overwriting somebody else's work. Obviously this is a problem
anytime you use "-f", but the fact that your "foo" branch is going
to somewhere besides the remote's "foo" branch makes me think it is
much more likely a clueless user will get confused and overwrite
something on the more "mainstream" branch.
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.
-Peff
--
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