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

On Mon, Mar 12, 2012 at 05:37:32PM +0100, Matthieu Moy wrote:

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.

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).

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