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

[Andreas Ericsson <ae@op5.se>]

On 03/13/2012 02:17 PM, 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'.


Sensible sentiments, sir.

Even with advanced usage, 'current' is what I think does the right
thing in 99% of all cases, and it errs on the side of "least extra
work when things go wrong".

The questions to ask, I think, are these:
* What would newcomers to git expect?
You answered this nicely.

* What does advanced users use *most of the time*?
At $dayjob, 99.9% of all pushes are to get the changes of the current
branch to the sharepoint repo. Once in a while (when tagging, usually
whatnot) for some repositories, I wish to push maint and master to a
public repository for the masses to use. This happens roughly once
every 200 commits, according to a quick "git log" in two repos, but
only for about 10 or so of the 60-odd repos we're maintaining, and
only for two of the six developers working on them.
It's very rare that I work on multiple already-created topics and
they all finish at the same time. At most, I wish to push "maint"
and "master" in one go.

If I notice I've done the bad push, I need to make sure noone else
fetched the thing during the time it takes me to undo the push, or
I may have to quickly fix up the potentially broken branch. Either
way, it can be a lot of work that I rarely have time for right then.


* What causes the least damage when the default is less suitable?
Quite a few times I've managed to push work-in-progress commits to
random topics at work with the default "matching". If I miss that
I've done so, undoing the damage is a great big pain in the butt,
since it means either force-pushing to sharepoint or un-bisectable
commits. The worst case for "current" would be if I merge one branch
to master, forget to push the merged branch but do push 'master'
to our sharepoint, and then someone else comes along and works a
bit more on the topic I accidentally didn't push. When that happens,
I can quite easily rebase my changes on top of the other devs, or
merge with the sharepoint changes, and then re-merge to master
without having to call a flag-day for the devs working on the same
project.

If I notice I've forgotten to push, I can just push again immediately
and git will handle any errors for me. It never leads to any extra
work for me, and never stalls anyone else from progressing with their
own tasks.


In light of that, "current" is really the only sensible way to go.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.