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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> ... This is not a push.default issue,
> but I think it is somewhat related, and maybe worth discussing along
> with the topic of asymmetry. ...
> I've mostly trained my fingers to type "git push
> <my-publish-repo>", but I do occasionally forget.

In an assymmetric set-up, you would typically push into one place
but update from one or more places, so it might make sense to make
it easier to say "git push" and "git pull $there".  But that does
not solve the fundamental issue, I would think.

> Do other people with
> asymmetric workflows find this annoying? Do they not care? Or are many
> fewer people doing asymmetric things than I think?

I think it is not "they do not care", but "they do not have a good
solution".  I do not think of anything offhand, either.

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

Because "upstream" is meant to be "For the branch I am on, you know
how the branches map between the remote repository, so you already
know what the right thing to do---do it" mode, the correct "guess"
in your case is to error out and say "Nah, you are not talking with
your upstream, so I do not have any clue what branches you want to
push out and how. As you said that the push.default is upstream, not
matching, I refuse to even do the matching push in your case.  This
is an error. Be more specific".

> 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 ... << and we
>   shouldn't discourage them from learning as it will be needed
>   anyway >>
>
>   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.
>   << the newbie may push -f ruining the work of others >>

I agree with both points.  Also there is a cross-variant issue of
the above two:

	If a new user hears "not fast-forward, first pull and then
	push again", that will be done on a topic branch, merging
	'master' back and then pushing the result to 'master',
	leaving the 'master' of the user behind.

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

I do not think "the most number of people" is a high-priority issue,
but "least damage" default may not be necessarily the best.

Obviously, "nothing" is the least-damage option, and looking at how
even people on this list cannot decide between current and upstream,
I actually am very tempted to suggest it as the new default.