Re: push.default: current vs upstream

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Jeff King <peff@peff.net> writes:

> On Thu, Apr 05, 2012 at 06:46:51PM +0200, Matthieu Moy wrote:
>
>> It seems rather natural to me to have "asymetric workflow, asymetric
>> commands" by default. So, if one wants to push to a place other than
>> upstream, say "git push public-repo branch", or set your upstream to
>> where you want to push (simple with "git push -u"), and say explicitely
>> "git pull repo branch".
>
> That makes sense _if_ the user is thinking about pull and push as
> symmetric commands. That may be immediately obvious for some people's
> mental models. But I suspect it is not for others (it is not for mine,
> though I obviously do not count as a beginner).

I think exactly the opposite. Once you learnt about remote-tracking
branches, about "git fetch" Vs "git pull", you understand why "git pull"
and "git push" are not strictly speaking symmetrical operations.

But just from the wording, it should be obvious that the commands are
doing something somehow symmetrical.

> So shouldn't the advice for a non-fast-forward push be:
>
>    if $source_ref is currently checked out
>            advise "git checkout $source_ref, and then..."
>    fi
>    if $dest_remote == branch.$source_ref.remote &&
>       $dest_ref == branch.$source_ref.merge
>            advise "git pull"
>    else
>            advise "git pull $dest_remote $dest_ref"
>    fi
>
> That handles only one ref, of course. If you get multiple non-ff
> failures, I'm not sure what we should advise.

The topic ct/advise-push-default does essentially that indeed.

> You wrote above that we'll have a hard time explaining how "git pull"
> works. But I don't think so; if it hasn't been a problem with
> "matching", then why would it with "current"?

I mis-spoke. I think I meant something like "if the assumption that
explaining push -c push.current=upstream is hard, then we'll have a hard
time explaining git pull".

> I'm less concerned with explaining and more concerned about safe
> defaults.

Yes, my rant about simplicity was a reply to Junio, who was arguing
about simplicity:

Junio C Hamano writes:

| Obviously the former ["current"] is much simpler to explain and understand, as
| people do not have to learn upstream tracking before doing their first
| "push".

Your arguments about safety are valid (we don't agree on the relative
importance), but I think the argument of simplicity simply doesn't hold.

About safety, I don't think we can tell in general which bad push is the
most serious. push.default=current may create branches unexpectedly,
while push.default=upstream would ask you to "push --set-upstream" when
creating the remote branch. push.default=upstream may push to the master
when you wanted to create a remote topic branch. My feeling is that both
are equally bad, but maybe I'm wrong here.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/