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

[Marc Branchaud <marcnarc@xiplink.com>]

On 12-03-13 09:17 AM, Junio C Hamano wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> 
>> There's a rule of thumb which works very well for beginners: when "git
>> push" tells you to pull before, then pull before. This rule of thumb
>> works, but only provided "push" and "pull" are symmetrical.
> 
> 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.
> Obviously "push and pull are symmetrical" holds true for that single
> branch workflow, but that does not mean a more complex workflow must
> be symmetrical.
> 
> Even though I think 'upstream' will be a superset of what 'current'
> wants to do in an ideal world where the user configures everything
> right (hence it ought to be the better default between the two), I
> do not think that the target audience "let's change the default"
> folks are trying to help is those who set @{upstream} correctly
> point the destination for a branch they want to push to and leave it
> unset for a strictly private branch. If we choose the default that
> would primarily make it efficient for people who can configure
> everything right, we are missing the point of this discussion. I
> think the target audience to be helped is the people who do not
> (yet) do anything complex, and the point of this discussion is to
> help them avoid getting surprised.
> 
> And by "surprised", I do not necessarily mean "dangerous". While we
> should aim to avoid "dangerous", we should avoid "ununderstandable"
> even more.
> 
> 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.
> 
> On the other hand, the user needs to know not just 'branch' but also
> understand the concept of @{upstream} in order to use 'upstream'
> without surprise.  When something goes wrong, prerequisite knowledge
> that is required to understand it is greater.  Also the current
> implementation of 'upstream' has some weird semantics (or undesigned
> bugs) pointed out by Peff, which would make it even more confusing.
> 
> That makes me suspect that 'current' might be a more appropriate
> default between the two. From that simple default, those in the
> "shared central repository" world can graduate to 'upstream' once
> they know what an 'upstream' is and how to take advantage of
> per-branch configuration.  Similarly, those in the "publish to be
> pulled" world would graduate to 'matching'.

Good points!

I think someone who's figuring out their workflow as they go would appreciate
the simplicity offered by "current".

You've changed my mind:  I now think "current" is the better default.

		M.