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

From: Matthieu Moy <[email-masked]>
Date: Tue, 13 Mar 2012 14:35:47 +0100

Junio C Hamano <[email-masked]> writes:

> I actually think the "pull before push again" was written with only
> CVS style non-branching workflow in mind, in other words, only to
> help somebody who works on his master against the central master.

It doesn't have much to do with branching/non-branching. You may use
branches, and still work collaboratively on them. There was an example
above in the same thread:

  http://thread.gmane.org/gmane.comp.version-control.git/192547/focus=192694

There are also cases like "I pushed from my laptop and I'm back to my
desktop", or "the content has been edited from GitHub's web interface".

Actually, I hardly see a case where "pull before push again" (with or
without --rebase or such) is wrong for a beginner.

> Pushing 'current' from a branch 'topic' forked from either 'master'
> or 'origin/master' will create a new branch 'topic' at the central
> repository. But that is straightforward and understandable. The user
> will see what happened in the feedback from the command, and there
> is no need for the user to be experienced enough to know the mapping
> of @{upstream} to understand why it happened.  "I am on 'topic' and
> I pushed, I created 'topic' there".  Very simple explanation exists.

Very simple explanation exist for what "push" does, but not for "the
global picture of what push and pull do". And really, the case "Git
prevents me from pushing, I don't know what to do" is a problem for
people who don't get the whole remote/branch/upstream/... things.

Actually, I'm starting to wonder if the whole "upstream" thing should
not be deactivated by default, and replaced with a simpler mechanism
like "pull.default", similar to what "push.default" does today. Then,
users could set "pull.default=current", and "git pull" would pull a
branch with the same name remotely. Or users could set
"pull.default=upstream" and get what Git does today.

But that's a much larger change, then ...

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