Re: push.default: current vs upstream

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: push.default: current vs upstream

From: Matthieu Moy <hidden>
Date: 2016-06-15 22:53:27

Junio C Hamano [off-list ref] writes:
Obviously the
former is much simpler to explain and understand, as people do not have to
learn upstream tracking before doing their first "push".
Again, this is simple only for people who never run "git pull" without
argument.

For the others, they already have to learn about the "upstream"
semantics. And making argumentless "git pull" and "git push" purposely
asymetric to make it simple for the user sounds like an oxymoron to me.

The discussion seems to focuse on 'let's make "git push" easy to
explain', but I think the right thing to do is to make _Git_ easy to
explain. With "push.default = current", we'll have a hard time
explaining how "git pull" works.

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

Re: push.default: current vs upstream

From: Jeff King <hidden>
Date: 2016-06-15 22:53:28

On Mon, Apr 02, 2012 at 09:40:22AM +0200, Matthieu Moy wrote:
For the others, they already have to learn about the "upstream"
semantics. And making argumentless "git pull" and "git push" purposely
asymetric to make it simple for the user sounds like an oxymoron to me.
We can make the operations technically symmetric in terms of the actual
sources and destinations from which commits are moved, but they are not
necessarily symmetric in the user's workflow.

Let's imagine I have a branch "topic" that has an upstream of
"origin/master". You are arguing that "git pull" moves commits from
"origin/master" onto "topic", and therefore "git push" should move
commits from "topic" onto "origin/master". That is symmetric at a low
level.

But what does it mean to me as a user? Those operations may not be
symmetric in my workflow if the branches have special meaning. For a
project using a topic-branch workflow, it is not big deal to move
commits from master onto a topic branch. But it _is_ a big deal to move
commits from a topic branch onto master, because that has social
implications within the project (e.g., saying "this topic is ready for
prime-time").

So yeah, the low-level symmetry provides one nice way of explaining
those commands when the symmetry is helpful to your workflow. But I'm
concerned about the cases where what the user wants _isn't_ symmetric.
When they say "git push" because they want to publish their topic
branch, and it does an embarrassing and difficult-to-revert thing to the
public master branch. Telling them "ah, but you should have seen that
pull and push are symmetric! It all makes sense!" is going to be small
consolation.

Fundamentally I am less concerned about explainibility and more about
safety when somebody has not even gotten to the point of having the
thing explained.
The discussion seems to focuse on 'let's make "git push" easy to
explain', but I think the right thing to do is to make _Git_ easy to
explain. With "push.default = current", we'll have a hard time
explaining how "git pull" works.
Do we have a hard time explaining how "git pull" works now?

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help