Re: push.default: current vs upstream

Jeff King [off-list ref] writes:

I would say without hesitation that fast-forwarding the upstream is more
likely to be disastrous than creating a new branch. However,
push.default=current can also fast-forward an existing branch (although
if you have a local "foo" and its upstream is _not_ the remote "foo", I
find it extremely unlikely that a remote "foo" also exists).

On the other hand, one thing we have not talked about is how one gets
into the "topic push fast-forwards master" situation. Which is running:

  $ git checkout -b topic origin/master

I'm not sure if that is something totally clueless people will run. And
maybe by the time people are intermediate enough git users to run that,
they will have figured out how upstream works. So maybe my concern is
overblown....

I already said that I do not deeply care either way, and it appears that
only you two are the ones who deeply care *and* have things to say that
are worth listening to (we've seen many "me too wants upstream" without
deep thought a few weeks ago against the RFD).  Whichever way you two
agree to go eventually, could you come up with a (hopefully) small summary
of caveats that can be pasted in the future release notes that switches
the default away from the matching?

E.g. "The new default is now 'upstream', which does mostly what new people
do, but the user should not allow the default kick in in these situations:
A, B, C..."  It might end up saying "The new default is now 'current',..."
but the point is that either semantics would need to come with a warning.

Thanks.