Re: [RFC PATCH] push: start warning upcoming default change for push.default
- From
Andreas Ericsson <ae@op5.se>
- Date
- Mar 13, 2012, 15:02 UTC
- Message-ID
- <4F5F619A.3040806@op5.se>
- In-Reply-To
- <7vehswljxi.fsf@alter.siamese.dyndns.org>
On 03/13/2012 02:17 PM, Junio C Hamano wrote:
Show 51 quoted lines
> 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.