Re: push.default: current vs upstream

[dragging Matthieu, an advocate for "upstream", into this]

Jeff King <peff@peff.net> writes:

Honestly speaking, I do not care too deeply either way. The difference between "mixed" and "current/upstream" is a very deep-rooted one and has much more to do with how "batchy" person you are, than if you are pushing to a shared or your own repository.

The underlying assumption for the original push semantics of "mixed" (or use of remote.$there.push configuration) is that the way you work is to prepare all your branches to be pushed $there ready by the time when you push $there. Concentrate perfecting your local work, perhaps even being oblivious to what others do in the meantime, and then push out everything in one go. The "oblivious to what others do" part is obviously harder to arrange if you are pushing into a shared repository, but the connection between the "shared repository workflow" and "push everything in one go" is not fundamental.

On the other hand, both "current/upstream" are for people whose work habit is to complete _only_ the current branch; when you push it out $there, it does not matter if the other branches that will eventually be pushed out to the same repository are ready.

And this "only the doneness of the current branch matter" is fundamentally different from "push everything in one go", and I am already happy to see that future Git is moving in this direction, which also matches the way vast majority of people seem to work. So in that sense, I do not care which one we picked between "current" and "upstream". Obviously the former is much simpler to explain and understand, as people do not have to learn upstream tracking before doing their first "push".

Yes. I think that is up to the people who favored "upstream" over "current" to share their anecdotes to polish such advice messages.

... which is this.

And the reason why it is surprising to the beginners is? Because "topic" and "master" (of "origin/master") are not the same name?

If you strip default features out of fear that it may be surprising to the beginners, you would end up telling them to always explicitly say what they want to push and to where, so we would need to draw a line somewhere. I tend to think that this is on the "understandable" side of the line (after all, I said "Let's start a topic to be merged to origin/master" when I started the topic, and I've been rebasing the topic up to date from time to time), but obviously you don't think so.

And I think your aversion to the "implicit fast-forward" will lead you to teach beginners to do this instead:

   $ git clone ...
   $ git checkout -b topic origin/master
   $ hack hack hack
   $ git checkout master
   $ git merge topic
   $ eyeball, test, think
   $ git push

which arguably is a more disciplined way, but I do not know if we can expect that people can be trained to be _that_ well disciplined.

If we were to take "upstream", as long as we commit to make it ready by the time we switch, I do not see it as much of an issue. Of course, the "will change to 'upstream'" message may need to be rephrased to say that the idiotic usages that would trigger bugs in the current "upstream" implementation I listed in the message you are referring to (which were actually taken from your earlier message, IIRC) are not supported and currently give undefined results, but will be fixed by the time we actually do the switch.